Gear pressure floor

changed the description

Can you explain the difference between your approach and the entropy floor approach we use? Ultimately it does the same thing. We set the entropy to a minimum and then the pressure gets recomputed and applied to the particles and interactions in exactly the same way as your pressure floor I think.

The key difference is that we do not modify the entropy (or energy), we only add a pressure in order to avoid the collapse of non resolved particles.

If you prefer, I can try to update the entropy_floor in order to deal with the pressure floor.

The idea is that we do not want to change the properties of the particle (otherwise the cooling will deeply change for low resolution particles). This additional pressure can be seen as the pressure from non resolved turbulence.

For more information, you can look at Revaz and Jablonka 2018, "Self regulated star formation..." by Hopkins et al. 2011.

Ok, I see. You want the additional entropy injection coming from the subgrid turbulence to only act at the level of the hydro solver but not affect the other subgrid models such as cooling and star formation.

However, looking at your implementation, I don't think it will do that. You will need to modify the pressure that enters the _iact() otherwise you won't change the behaviour of the hydro solver and the gas will still collapse under gravity. The hydro_get_XXX are not used internally by the hydro. They only provide values to the external world, i.e. subgrid.

Let me think about what is best in terms of design then.

Thanks I forgot P_over_rho2.

The question is more about the design than the details, I still need to do a few things and test it deeply.

Ok. Then the whole thing makes sense to me.

Let me think a bit about the design and the best way to integrate this with the rest. At this stage, I agree with you, we probably do not want to update "our" entropy floor as the behaviour is not the same.

added 1 commit

ef8d75d8 - PressureFloor: add missing pressure floors

Compare with previous version

Ok. I think what you have done makes sense and it likely the best choice.

However, we will have to be very careful not to break things when implementing this in the other schemes. The assumption thus far was that we do not call the hydro_get_XXX() from within the other functions. This is because the hydro_get_XXX() functions may just return quantities that are computed by the other functions (e.g. predict_extra) and that would hence make the whole thing circular.

added 1 commit

6c300dbb - PressureFloor: do not use hydro_get_pressure in hydro.h

Compare with previous version

@yvesrevaz

This is the small cosmo volume example, with the grackle cooling, with (green) and without pressure floor (black) at z=0. I am using the Gadget2 SPH.

You can see that the gas is not allowed to reach very high densities with the pressure floor.

I am starting to implement the pressure-* schemes, it should be done before the end of the day.

So I will not do P-A as it is not fully implemented and the P-U is more complicated than expected.

For P-U, in the acceleration, we need the derivative of the pressure with the pressure floor. Therefore it seems that we need a third loop. I will investigate how to deal with it and come back afterward. It may take a while.

I now understand how to implement the pressure floor to any kind of SPH, you simply need to use equation 12 of Hopkins 2013 and replace the pressure in it. Even if the y corresponds to the pressure, they are still only a weight and should not be influenced by the pressure floor.

I simulated the small cosmo volume with the P-U, but now I have the time step that falls to below dt_min (which is not the case with Gadget-2 SPH with pressure floor). This should be my last step (along with the doc) for this merge request.

This is the same graph than before but with P-U.

We can see that we recover the same kind of behavior than with Gadget-2. The only difference is the presence of particles at high density and low temperature.