yes, I am using Enzo.
I am sure that my gravitational field does not include the particles, in fact the gravity contribution of their masses is missing from the potential (I am not using standard dark matter particles and I think the contribution to gravity of this particle type is added after Enzo computes the standard potential field). In fact if for example I plot the equipotential contours for the default Grav_Potential I get just the equipotential surfaces for the gas.
I dug in yt yesterday to understand what was going on and why it did not like my potential, in fact I checked exactly the quantities you asked me for bot Grav_Potential and my user defined Total_Grav_Potential (in cgs):
In : grav_pot.min()
In : grav_pot.max()
In : grav_pot.size
In : tot_grav_pot.min()
In : tot_grav_pot.max()
In : tot_grav_pot.size
I checked that the values were changing correctly as the sum of the the three partial potentials (gas, part1 and part2), and they are ok. Also the total length of the array is ok. So what I did next was defining the Total_Grav_Potential field as
#adds the current particle potential to the total potential
total_grav_potential = data['Grav_Potential']
so that it just returned the standard Grav_Potential field. Also in this case the result was the same, i.e. I got the same error if clim was not defined and no contours when clim was defined. Hence the problem was in how the field was added to the yt fields.
I went checking the Creating Derived Fields page in the yt docs and the fields.py file from my yt to see how fields were created, so I started adding parameters to the add_field() function one at the time to understand if they were responsible for the problem.
Turned out that the validators were the problem, in particular I had to validate the following fields:
which are the exactly the native Enzo fields that I used inside the function definition (the used derived fields are instead ok!). So in the end I used this:
take_log= False , \
particle_type= True, \
vector_field= False, \
and now I get the contours.
The problem is solved but I do not really quite understand why the native Enzo fields have to be validated.
Can I ask you if you can explain me what is happening in your opinion?
Concerning the coding suggestions, looks definitely better to do the conversions at the end and use more derived fields, I will rewrite it starting from your template.
Thank you very much for the help!