Ensure outputed indexLevels correct

[pwolfram]

Under new developments with free floating and surface particles, ensure that outputed indexLevels are updated to correspond to each particle type.

[pwolfram]

cc @bradyrx @maltrud

[pwolfram]

@bradyrx, this is just something we should check on #2 before merging and the final production runs.

[bradyrx]

@pwolfram,

A quick check shows that indexLevels are not updated to correspond to particle type. I looked at unique values for indexLevel for a particle output file with passive, surface, and isopycnal floats. We should see [1,3,4] but only see [1] (surface).

Perhaps the issue is here in the make particle file? It looks like it always returns 1.

[bradyrx]

@pwolfram ,

I might be misinterpreting this issue. Looking at verticalTreatment produces [1,3,4] and correctly identifies the particle type. What should indexLevel be printing out?

[pwolfram]

@bradyrx, indexLevel should give the cell id in the vertical corresponding to the z depth of the particle, e.g., an index one can use to understand the boundary box for the particle in the vertical.

[pwolfram]

Just to be clear here-- surface particles should always have an indexLevel=1 (Fortran top-layer of column). But, if we don't have more than one type over all time this means there is a bug in the code and it isn't updated correctly, which seems to be the case because free-floating and isopycnal floats are used.

[bradyrx]

@pwolfram, thanks for the clarification. You are correct. I checked again for the passive, surface, isopycnal case and there is in fact [1, 3, 4] for vertical treatment type but just [1] for indexLevel.

[pwolfram]

@bradyrx, are you aware of any issue with indexLevel output not being correct?

[bradyrx]

@pwolfram , if no updates were made to indexLevel, then my previous comment should hold.

Just re-checked on most recent commit from #21 and this issue still holds. I seeded 20 passive particles in the vertical and ran np.unique on particles.nc and found only [1] for indexLevel.

[pwolfram]

@bradyrx, you never saw indexLevel=0, right? This would be the biggest thing, e.g., it not getting updated properly.

[bradyrx]

@pwolfram, correct. Also just checked the 60-day 240km run and still only have an indexLevel of 1 for all particles over the 60-day integration.

See here:

/lustre/scratch3/turquoise/rileybrady/ACME/cases/GMPAS-IAF.T62_oQU240.grizzly.512o.96i.5ParticleLayers.Ton.Son/run