Not all data available – in #10: INT2LM

in #10: INT2LM

Ha, that is interesting.

So the test that crashed was done with int2lm_131101_2.00_clm2, using the intel compiler.
I just tried with int2lm_131101_2.00_clm3, compiled with gcc, and that works well.

The reason I switched to our intel version was that, for the 0.22° preprocessing, the gcc compiler options appeared to be sensitive to boundary violations (see bug int2lm). This was not a problem for our intel compiled version.

And now there seems to be an inverse sensitivity? Or it could be related due to differences between the two versions?
No time to test this now, but if this would be relevant, I can test this later on?

  @matthiasdemuzere in #61b63f0

Ha, that is interesting.

So the test that crashed was done with int2lm_131101_2.00_clm2, using the intel compiler.
I just tried with int2lm_131101_2.00_clm3, compiled with gcc, and that works well.

The reason I switched to our intel version was that, for the 0.22° preprocessing, the gcc compiler options appeared to be sensitive to boundary violations (see bug int2lm). This was not a problem for our intel compiled version.

And now there seems to be an inverse sensitivity? Or it could be related due to differences between the two versions?
No time to test this now, but if this would be relevant, I can test this later on?

Ha, that is interesting.

So the test that crashed was done with int2lm_131101_2.00_clm2, using the intel compiler.
I just tried with int2lm_131101_2.00_clm3, compiled with gcc, and that works well.

The reason I switched to our intel version was that, for the 0.22° preprocessing, the gcc compiler options appeared to be sensitive to boundary violations (see bug int2lm). This was not a problem for our intel compiled version.

And now there seems to be an inverse sensitivity? Or it could be related due to differences between the two versions?
No time to test this now, but if this would be relevant, I can test this later on?