Unable to export to and run with OpenFOAM 1.7, 2.0 and 2.1

[wyldckat]

Original Report:

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
19	[enGrid] bug	major	always	2012-03-14 11:43	2012-04-09 09:27
Reporter:	wyldckat	Platform:
Assigned To:	wyldckat	OS:
Priority:	normal	OS Version:
Status:	assigned	Product Version:	1.3beta
Product Build:		Resolution:	open
Projection:	none
ETA:	none
Summary:	Unable to export to and run with OpenFOAM 1.7, 2.0 and 2.1
Description:	This is a half-bug/half-feature request, because enGrid 1.3.0 is still not fully compatible with OpenFOAM versions (at least) after 1.6.x. The necessary changes are: * Exporting the case, with the file structure compliant with the latest versions. At least fvSchemes/divSchemes needs reviewing. * For launching the solvers, it's necessary to update how the environment is handled. It's also possible that this was a problem only on Windows, but most likely the issue is related to problems with where the builds are located now. The current version places all builds inside a "platforms" folder.
Steps To Reproduce:
Additional Information:
Attached Files:

[wyldckat]

Notes
(0000066)
ogloth
2012-03-30 10:28	Would you want to help out with this? I could offer to explain (via TeamViewer) how the file template mechanism works. I also think that adding more solvers would be beneficial. -- Oliver
(0000067)
wyldckat
2012-03-30 10:33	I do want to help, problem is that I don't know when I'll be able to help. -- Bruno
(0000069)
wyldckat
2012-04-09 09:27	Keeping track of the development information here: http://engits.eu/wiki/index.php/Development#Upgrading_compatibility_for_OpenFOAM_1.7_and_above [^]

[wyldckat]

The location on the new wiki for the notes about this: Upgrading compatibility for OpenFOAM 1.7 and above

I've been thinking a while about this and I haven't come to a conclusion on what is both the best, quickest and most generic and future proof method for upgrading the infrastructure that interacts with OpenFOAM.
The conclusions I've got so far are:

1. One requires the user to run a script or enGrid with a dedicated option, while the OpenFOAM environment is activated. The collected information would then be stored in enGrid's configuration folder provided by Qt's settings system.
   • Pro: On size fits all.
   • Con: One script for running in Linux/Mac/MSys and one batch file for Windows in command line mode. Maintenance of these files could be a bit bothersome.
2. Another relies directly on OpenFOAM's bashrc.
   • The downside is that this would require to always rely on scripts for running things... which might not go very well when we want to terminate the application...
   • The other possibility would be to launch the shell binary directly into a new console and control it directly via stream functions... sending a SIGEND to the controlled shell would possibly kill off all child processes.
3. Yet another is to use the same template system used for the solvers, but adapted to each OpenFOAM version's folder structure.
   • This would require the user to manually define the architecture to be used, the mpi name and the base locations for OpenFOAM's main folder and ThirdParty folder, if any.
4. The quickest one is the one that requires the user to launch enGrid from a working OpenFOAM terminal shell.
   • Con: This would make it nearly impossible to run OpenFOAM applications from the start menu.

Probably the third one is the preferred option, which might be the easiest to maintain and configure... although it might not support contorted installations...
Although the 2nd one has a nice appeal, since it would only require a single line for the script or batch file to be sourced/executed at the beginning of the control system for the application.

[wyldckat]

The following commits seem to take care of a big part of this task:

• 3f3da43
• e764c94