[shreyasr]

HI Everybody,

I'm in the process of writing a program (GUI based on Tkinter) which will allow the user to select multiple simulation input files for CFX.

I intend the program to work on both Windows/Linux and to be portable.

Current problem : on DOS (on Windows 7)
"<path to cfx5solve>\cfx5solve.exe -def <path to def file>.def"
doesnt work. DOS remains busy for a few minutes, and nothing happens.

NOTE:
Entering : "<path to cfx5solve>\cfx5solve.exe" does work and the CFX Solve manager starts up. But I need to provide the arguments and input files via the script.

Looking forward to your suggestions !

[ghorrocks]

Does it work if you use a command line window started from the CFX launcher? Then the path to the CFX executables is already set and you can just call "cfx5solve" with no path.

And is the def file in the current directory? If so then you can ignore the path to the def file too.

No idea what is causing your problem but you just need to play with some options to figure it out.

[shreyasr]

Hi Glenn,
Yes - typing in "cfx5solve -eg StaticMixer" in the Command Line started by the CFX launcher does work.

However, using only "cfx5solve" from a command line terminal called from outside CFX doesn't work, the paths aren't set then. I need to key in the complete path to the exe file. Is this something like the different bashrc profiles in Linux ?

I'd prefer using the compete path, for both the cfx5solve file and the working folder with the input def files - because I intend to have them stored in variables, in a 'settings' option in the program : this the user can set, thus making the program portable, and I can access input files from any folder.

No, the .def file was not in the same directory as the cfx5solve exe.

I've been using scripts with the paths explicitly defined on a RHEL OS, with arguments for the number of cores and the start method, and that has always worked fine ! I haven't tried this GUI program on it, yet, but I expect fewer hassles than on windows.

It seems quite strange that I'm unable to pass arguments to the cfx5solve launch command, via DOS.
I'm still trying to find the magic 'syntax' combination !

[shreyasr]

Hi,

It does work via the usual command line as well.
Procedure I followed :
1.Start > cmd
2. manually navigated to the location of the cfx5solve.exe (using cd)
3. keyed in : cfx5solve -def <path to file>\StaticMixer.def
If there are spaces in the path to the input file , then enclosing within double quotes "<path to file>\test.def"

The important thing is that : the .out and .res files are saved into the location of cfx5solve , rather than the location of the input file.
In RHEL, the output files are saved into the location of the input file.

However !
If instead of manually navigating to the location of the cfx5solve directory, I try :
"<path to cfx5solve>\cfx5solve" -def "<path to def file>\StaticMixer.def"
I get the error message :- unable to create C:\Program Files\StaticMixer_001.dir : permission denied

I don't know why it's trying to create the out file in the Program Files folder.
The location of the input file, is C:\TESTER\StaticMixer.def

[ghorrocks]

I think you misunderstood one of my points. I asked is the current directory the directory where the def file is located? If not then CFX will put the temporary directory somewhere else and that is not a good idea in general.

So I recommend your script be something like:
cd <directory containing def file>
<CFX PATH>cfx5solve -def <def file name, with no path>

The def file will not require a path if it is the current directory, and the temporary files will be put in this directory.

[shreyasr]

Sorry for the misunderstanding.

But, I understand your point now. That is exactly what happened.
I was thinking, CFX would use the input files path/location for the temp files.

I will try your approach, and I think that's the right way to do it too.

However, the good news for now, is that I've got the simulations running via the GUI program!

In this case : the output files were stored at the location of the python script itself.
(note : the input file is at another location and the same line of code doesnt work on the DOS terminal)