-   Linux - Software (
-   -   Fortran error reading line (

chiendarret 05-24-2020 11:00 AM

Fortran error reading line
1 Attachment(s)
On trying to read a molecular volumetric (cube) file with MOLDEN, error


At line 923 of file rdgaus.f (unit = 21, file = 'mep.cube')
Fortran runtime error: Bad value during floating point read
line 923 is highlighted in the attached screenshot and I don't see any difference with respect to the other lines. Also, as far as I can view, line 923 conforms to the standard of GAUSSIAN CUBE files that are usually read by MOLDEN.

I hope that someone can see better than me.

shruggy 05-24-2020 12:04 PM

Wait, the error message says it choked on line 923 of fortran file rdgaus.f when trying to read from mep.cube. It doesn't say what line in the input data file is wrong.

Try something silly like

awk '{for(i=1;i<=NF;i++)printf "%f ",$i;print""}' mep.cube
to see if awk can read the data.

pan64 05-24-2020 01:27 PM

additionally you may try (for example) od -xc mep.cube to see if there was something illegal (incorrect char) in it.
But first you need to find at least the approximate location (line number?) in that file.

chiendarret 05-25-2020 02:45 AM

mep.cube could be read and nothing illegal came out. Suspecting a shortage of memory I tried on a linux box with more ram: same error.

I tried a small cube file for water (taken from the web) and MOLDEN showed correctly the map, colored by atomic charges.

therefore, I have now submitted the issue to the author of MOLDEN. probably the python software that I used to generate the cube file from ORCA data (as from my post of a week ago) does not provide a full standard.

it is not rare that we loose more time on visualization tools than on the scientific core problem


pan64 05-25-2020 03:23 AM

if you could modify rdgaus.f (around line 923) you may have better information on the issue. Add some logs or debug info.

shruggy 05-25-2020 08:14 AM


Originally Posted by chiendarret (Post 6127025)
mep.cube could be read and nothing illegal came out.

After trying it out myself I realized that awk won't catch any badly formatted floating numbers anyway because it's too tolerant to what it gets on input. I tested it with this data:

-1.22372e-01  -1.21192e-01
-2.04038e-01  -2.03724e-O1  -2.03209e-01  -2.O2502e-01  -2.01616e-01  -2.00565e-01

I changed 0 (zero) to O (capital letter O) in two places marked red. And the awk output was:

-0.122372 -0.121192
-0.204038 -2.037240 -0.203209 -2.000000 -0.201616 -0.200565

As you can see, it just converted good parts of bad numbers up to an illegal character.

So, then I put my hope into anomaly, or datamash, or miller, or num-utils. As if! All those great tools (and I'm not sarcastic here, they are really great!) are designed according to the robustness principle: they would just silently discard any data that are not properly formatted numbers.

I ended up with the following solutions.

First, my test file:

$ cat mep.cube
The first comment line
The second comment line
-2 0.1 0.2 0.3 6
7 0.4 0.5 0.6
8 0.7 0.8 0.9
9 0.5 0.4 0.3
1 0.0 0.1 0.2 0.3
2 0.0 0.1 0.2 0.3
4 8 9
1 7 8 9
2 6 7 8
3 5 6 7
4 4 5 6
-1.22372e-01  -1.21192e-01
-2.04038e-01  -2.03724e-O1  -2.03209e-01  -2.O2502e-01  -2.01616e-01  -2.00565e-01

The first solution is quite simple, just check for illegal characters with grep:

$ tail -n+3 mep.cube|grep --color -Pn '[^-\s\d.e]'
13:-2.04038e-01  -2.03724e-O1  -2.03209e-01  -2.O2502e-01  -2.01616e-01  -2.00565e-01

You can do it in one command with sed, but sed won't colorize the matching parts:

$ sed -n '1,2d;/[^-\t 0-9.e]/p' mep.cube
-2.04038e-01  -2.03724e-O1  -2.03209e-01  -2.O2502e-01  -2.01616e-01  -2.00565e-01

OTOH, you'll get the exact line numbers that aren't off by two because of tail. Just replace p with = in the sed expression above, or add it like this:

sed '1,2d;/[^- 0-9.e]/!d;=' mep.cube
The second solution tries to validate the data, adjust it as needed:

  if ($1 < 0) {
    natoms=-$1; dset=1
  } else {
    natoms=$1;  dset=0
NR==(6+natoms+dset) {
  if (dset) ndset=$1
NR>(6+natoms+dset+ndset) {
  for (i=1; i<=NF; i++)
    if ($i < -0.3 || $i > -0.1 )
      print "line",NR,"field",i,"value",$i

chiendarret 05-27-2020 01:12 AM

I could not follow all the procedure in the last post, however, what I can now say is that MOLDEN does not open the so called .cube file from ORCA because the ".cube" extension is no standard. Each package outputs its own type of .cube file and MOLDEN is not prepared to the ".cube" from ORCA (it opens three other types of .cube). One could say - and I would agree to clear from confusion - that each non standard cube file (which is proprietary) should not have the .cube extension.

I contacted MOLDEN, which perhaps will take into consideration in the future my request to support ORCA (which has become the most used QM package, particularly on large clusters). Because all other visualization free packages that I tried do not attain the quality of MOLDEN (actually - in my hands - they produce plots of the electrostatic potential that could hardly be used for publication), the solution would be to adapt (the python script that converts ORCA electrostatic potential data into a cube file) to output a cube file type supported by MOLDEN. This could only be done by a software engineer not by a biochemist as I am. And it would greatly serve the scientific community.

All times are GMT -5. The time now is 05:17 PM.