Example simulation 201 fails using Intel compiler about u-dales HOT 10 CLOSED

@bss116 this has no assignee -- are you looking into this already or do you want to me have a look? If so could you please assign me to it? If so may have some time at the end of next week.

from u-dales.

I'm not going to look into this, at least for a while now. Sure, if you have some time, please have a look! But don't spend all your time and nerves on it, it will probably involve going over lots of array-bound warnings, for which we will need to allocate some time, sometime...

from u-dales.

OK I must have misunderstood the issue then -- I though this was something to do with the HPC specifically but I think this a general issue with Intel (flag) that catches a general problem that is not covered when running with GNU -- I will un-assign myself then 🤭...

from u-dales.

Yeah I'm afraid so... 😄

from u-dales.

@bss116 cool but in this case I would probably change the title to something a bit more specific as it is not due to the HPC per se. This only happens because you use Intel on the HPC rather than GNU so this issue is about Intel.

from u-dales.

@bss116 @samoliverowens I have checked this again running 201 for 1000 s both with Intel and GNU and on the ICL cluster. The first thing I noticed is that in both cases simulations run when using 1 core without errors. Then simulations do fail consistently across compilers but for seems to be related with the number of cores used. E.g. with 32 cores the simulation runs but with 48 it fails with error STOP 1 at the very first time step. I was therefore unable to reproduce the errors you shown in your attached logs and I wonder if this is become of some of the changes we made since this issue was opened.

So I think we should close this issue as it does not seem to apply any longer -- at least for 201 -- and, instead (1) clarify/add a check for the n cores to use and improve the error logs. I think that the for (1) we could simply clarify this in the docs for now with the option to implement a check in the code (future milestone) and for (2) add target it in future milestone. What do you guys think?

from u-dales.

@bss116 @samoliverowens I have checked this again running 201 for 1000 s both with Intel and GNU and on the ICL cluster. The first thing I noticed is that in both cases simulations run when using 1 core without errors. Then simulations do fail consistently across compilers but for seems to be related with the number of cores used. E.g. with 32 cores the simulation runs but with 48 it fails with error STOP 1 at the very first time step. I was therefore unable to reproduce the errors you shown in your attached logs and I wonder if this is become of some of the changes we made since this issue was opened.

The number of cores has to divide jtot, which for 201 is 128, so 48 will error.

from u-dales.

The number of cores has to divide jtot, which for 201 is 128, so 48 will error.

this is good then -- has this been documented? If so I would close this and open and issue about adding a check that can be targeted in a future release

from u-dales.

The number of cores has to divide jtot, which for 201 is 128, so 48 will error.

this is good then -- has this been documented? If so I would close this and open and issue about adding a check that can be targeted in a future release

I thought we already mentioned it somewhere, but I cannot find it in the docs now. Where do you think would be a good place? In the getting started guide under Run, or in the simulation setup notes?
The code fails because of this check at startup, so you'd already get this information in the output.xxx file:

I'm happy that 201 runs now also on the ICL cluster. Let's close this issue.

from u-dales.

@bss116 cool -- how about under https://github.com/uDALES/u-dales/blob/master/docs/udales-getting-started.md#run?

And sure -- will close this and open an issue for fixing that check. Will actually put this under 0.1 and I can take care of this.

from u-dales.