dassl: CRITICAL: Renaming of RWORK file(s) failed. (renameIntermediateFiles())

[nickvandewiele]

Hey,

i was trying to install RMG from scratch on my local ubuntu machine. everything goes smoothly: "make" assembles everything including dasslAUTO.EXE. Then i try to run the minimal example and it crashes (exit value "2") and logs:

"CRITICAL: Renaming of RWORK file(s) failed. (renameIntermediateFiles())"

The ODESolver folder contains the SolverInput.data file. The above message is thrown because RWORK and IWORK were not written (they can thus not be renamed neither).

The exception is thrown in JDASSL.java. In that piece of code it says that RWORK and IWORK might not necessarily be written out before the actual DAE solver step, but afterwards they should certainly be renamed...anyways, besides the absence of RWORK, and IWORK, SolverOutput.dat was not present neither.

Does anybody have a clue of what i am doing wrong here? might it be related to the platform (linux) where chmod's are necessary? (all executables were set to code 777)

[nickvandewiele]

Contents of SolverInput.dat:

2   2   1   9.02761072354529E-7 1
9.027610723545292E-6 0.0 
0.0 0.0 
0.0 1000000.0
0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 
1.0E-8 1.0E-18
1350.0 101325.0
1
2 1 2 2 0 1 0 0 1 
2.3583627097135633E13 0.0 0.0 0.0 9.970697099720738E10 
0

0

0

0.1 0.1
3 2
1 2 1 0 0 1 2 0 1.251675579761216
2 2 1 2 0 1 3 0 2.403317801337813E10
0 0 0 

[rwest]

Have you tried running that input file into dasslauto.exe? I think you mit need to pipe it in (eg. Something like $RMG/bin/dasslAUTO.exe < SolverInput.txt ). Does everything have permission to write to the folder(s) where things are running?

[nickvandewiele]

Does everything have permission to write to the folder(s) where things are running?

well, ODESolver is the folder where everything is written. It is created by RMG, and has all permissions (rwx).

[nickvandewiele]

Have you tried running that input file into dasslauto.exe? I think you mit need to pipe it in (eg. Something like $RMG/bin/dasslAUTO.exe < SolverInput.txt ).

When i do that inside ODESolver it says Aborted (core dumped)

[rwest]

1) can you run that solverinput on a known-to-work installation on another machine? 2) were there any warnings when making dasslauto?

[rwest]

@nickvandewiele, did you figure this out? If so, can you summarize findings and close the issue?

[nickvandewiele]

No, not yet.

[connie]

Nick- have you been able to fix this problem? I am getting the same error message on my local machine but not on pharos.

[connie]

I've solved my own problem. Was using gfortran from gcc version 4.6.3 where this failed. By upgrading to gfortran4.7 it now works fine. I think we might need to expand the gfortran versions that the Makefile warns about.

[nickvandewiele]

I haven't looked into this any more since then. It's very tempting to use the good ol' stable Pharos, and not run into 1 googol of problems on a new system before actually starting the work you should do. :)

anyways: was your local machine linux? if so, then I think you probably have solved the problem for me too. Didn't @rwest include already a warning in Makefile for these versions of gcc. I know that with the latest patches in speed up for GATP, gcc4.6 was not of any good neither.

[nickvandewiele]

the bottomline in it all is that I (we) spend some significant amount of time, looking in the wrong places (like java code, admin rights, nerdy linux stuff), and not fixing other stuff meanwhile. would it make sense to have a look at how rmg-py handles errors?

[nickvandewiele]

Here are the instructions to switch to gfortran-4.7 on Ubuntu-12.04 in order not to bump into this issue.

On Ubuntu 12.04, gfortran-4.6 is used by default. You need to download and install v4.7:

sudo apt-get install gfortran-4.7

Next, both versions will co-exist on your system, while v4.6 will still be default. Thus, change the default version to v4.7:

sudo update-alternatives --install /usr/bin/gfortran gfortran /usr/bin/gfortran-4.6 60
sudo update-alternatives --install /usr/bin/gfortran gfortran /usr/bin/gfortran-4.7 40
sudo update-alternatives --config gcc

The latter command will allow you choosing v4.7 as the default.

Check that v4.7 is chosen:

gfortran --version //should print 4.7 rather than 4.6

Finally, go to the home directory of RMG-Java, erase the current build executables, and replace them with the newly compiled ones:

cd $RMG;make clean;make

[Alborzi]

Dear all, I am using the latest RMG compiled form the source code on windows 7 and getting the same error. I tried to run the input file into dassl auto as RWest has suggested but the Dassl alone works and it creates IWORK_0.Dat and RWORK_0.Dat respectively.
Any suggestion is much appreciated. Ehsan Alborzi

[DetlevCM]

Just throwing in another comment - fiddling with RMG again, I saw the error as well, for the first time only once on my desktop.

Does anybody here know if there is some kind of timeout involved? I'm specculating, but it looks to me as if the desired event (file name change etc.) does not occur fast enough it fails.

[nickvandewiele]

I do not have extensive experience with compiling RMG on Windows (and certainly not with Win 7). Nevertheless, previous compilation issues on linux machines were related to the used compilers and versions.

1) Did you compile the fortran source code on windows yourself, or did you copy the DASSL.exe executable from sourceforge? If compiled yourself, could you show how you did that? That way, I can figure out if I can reproduce it.

2) Could you elaborate on the compilers and versions that were used to compile the fortran code?

[DetlevCM]

Well, I was the tech support - so I think I can answer that:

On Windows one has two options, MinGW or TDM - I prefer TDM because it is easier for 64bit, however we need 32bit for RMG, but fine. 1) Install TDM (the bin folder must be in PATH) http://tdm-gcc.tdragon.net/ 2) install a Java JDK and set JAVA_HOME to the root of the Java install - typically C:\Program Files\Java\jdk_xx_xx_xx 3) download the ant binaries, and add the bin to PATH http://ant.apache.org/bindownload.cgi 4) patch the "make.bat" - change g95 to gfortran

In a command line run make or run make.bat, then do "ant jar" to build the java executable, done. This builds all executables from source.

Currently TDM GCC supplies GCC 4.9.2

The error occurs regularly on Ehsan's laptop on the Desktop - we tried copying over a compiled version from my desktop (it works on my desktop) which also failed on his laptop. I was suspecting some form of file locking, BUT there is no reason why this should occur...