Minor optimization in bisection_iter

This is a tiny line that I had on cosma but didn't commit before cosma had its downtime.

It returns the minimum energy, when the lower bound is smaller or equal to the minimum energy and there is still a net cooling (LambdaNet_cgs < 0).

Edit: Sorry, merge request went into SWIFTsim instead of the colibre version.

@matthieu This initialisation is a bit dangerous. The problematic value is only caught with the SWIFT_DEBUG_CHECKS on. In all other cases, it leads to a segfault (@folkert reported this behaviour) as the interpolation routine tries to access a negative index and a negative delta. I think it would be saver to initialise these values with:

iden_eq = iden; dden_eq = dden;

This way it reverts back to the hydro density if it doesn't find a subgrid solution. This will usually only happen close to where the EOS meets the thermal equilibrium temperature and the hydro density would be the solution anyway.

So, it's expected behaviour to not find indices in some cases?

Yes, it can happen close to the intersection of the thermal equilibrium temperature function and the EOS. We put particles on the subgrid properties if they are within, say 0.5 dex of the EOS. It's possible that the particle is therefore above the EOS but below the thermal equilibrium line. The code snippet only finds solutions when the EOS is above the thermal equilibrium line. That's not a big problem, as for these cases we can just use the hydro variables.

Ok. Happy to change it then.

Maybe @folkert can quickly try it out and report back if it solves his segfault.

No, it doesn't solve my segfault.

Can you catch which table interpolation breaks?

It is this table interpolation: cooling/COLIBRE/interpolate.h:interpolation_4d_no_w():700: Invalid dz=-2.538653e-01

In ddt if you type bt, you get the stack of all function calls. That will tell us where it is.

Yes, but interpolation_4d_no_w is only called to get the hydrogen fractions and dz refers to dden_eq in all three calls. That's why it has to be the culprit. But it might get a weird value at a different point.

bt says that the error is caused by an error in libc in interpolation_4d_no_w.

Is that something that happens right at the start or later in the simulation? I cannot reproduce this at the moment with my version. Does it always happen at the same timestep? Can you maybe check how dz got a negative value?

Do you run with use_HIIregions 0? There seems to be a bug here. I get a segfault at before / at the first timestep if I try to run without HII regions. I don't know if this is related but I'll check that right away.

Yes, I am actually not running with HII regions so I use use_HIIregions 0. My code crashes after around 30 timesteps.

Okay, that might be related. I'll try to push a fix early tomorrow.

In the meantime, you can try to set use_HIIregions 1 and HIIregion_maxage_Myr 0. to run without HII regions.

The difference is that with use_HIIregions 0 the hdf5 file is not even read in and some arrays are not allocated, but maybe at some point some parameter from this file might still be necessary. I'll check it tomorrow morning.

closed

changed the description