Creating zoom IC with gas and custom particle types

[robmost]

Hi,

I'm trying to create hydro zoom initial conditions where the dark matter particles at every level have a different GADGET particle type so that I can check for contamination. My goal is to set the DM in the coarsest level to particle type 5 and in the zoomed region have the DM set to particle type 1 and the gas to particle type 0.

For a two-level grid, I believe this should be possible with the following parameter file:

# Cosmology
Om     0.3111
TCMB   2.7255
Ol     0.6889
Ob     0.0489
hubble 0.6766
s8     0.8102
ns     0.9665 
z      127

# Transfer functions
camb	./test_ic_zoom/test_ics_zoom00_tk.dat

# Seed
random_seed 192837465

# Specify the base-level grid. Basegrid 75 Mpc/h, 128^3
base_grid 75.0 128
gadget_particle_type 5

# Zoom region #1
centre 37.5 37.5 37.5
select_cube 22.5
zoom_grid 2 128
gadget_particle_type 1

centre_output

done

However, the resulting IC defaults to particle type 1 for both the DM particles in the coarse and the zoomed region. Only by disabling the gas and creating DM-only ICs, i.e. commenting Ob in the parameter file, I can obtain the DM particle types I want.

I see that AddGasMapper() definition in gasmapper.hpp requires default particle types for DM, can that be changed after the initial gas particle assignment in the zoomed region?

[apontzen]

Yes, because gadget uses particle types to identify gas, it didn't seem to make sense to have baryons and custom particle types simultaneously. Various flavours of gadget/arepo (e.g. Eagle and TNG) seem to have the facility to 'copy' zoom DM particles into gas for initialisation purposes, so that might be the way to go if you want to use custom particle types alongside gas.

That said, from the looks of it, this would actually not be particularly hard to fix if it's important to your use case?

[robmost]

I'm trying to replicate some MUSIC initial conditions, and for that, I would need to be able to differentiate between low-resolution dark matter particles from the ones in the zoomed region(s) + the gas particles.

For the setup I'm interested in, i.e. a 75 Mpc/h box with 1024^3 particles in the coarse region and at least 4096^3 in the zoomed region, the amount of memory MUSIC requires due to its implementation is considerable. On top of that, the latest public release has no MPI implementation, so the memory requirements are too big for the machine I'm working on. I was hoping I could generate them with genetIC.

[apontzen]

Please try using this branch: #106

Hopefully this fixes your issue, let me know!

[robmost]

I don't think it worked.

Using the .param file I posted before now I get gas particles as type 1 GADGET particles and DM particles (both low and high-resolution ones) as type 5 GADGET particles. It seems that the "gadget_particle_type 1" line is setting the gas type instead of the high-resolution DM GADGET type. I want to keep gas as particle 0 and have particle 1 for high-resolution DM and particle type 5 for low-resolution DM.

Am I missing something?

[apontzen]

I am not sure how this can be happening. It seems to work fine for me. (Note I had to add outformat gadget3 to your example script above, since it was missing a format specification)

Could you post the output that genetIC gives you when you try?

It should look like this:

genetIC v1.3.6, compiled: May 13 2022, 16:27:50
                 runtime: May 14 2022, 13:18:42

git HEAD:bb13592
 2022-05-14 13:18:42
 2022-05-14 13:18:42   Limiting number of FFTW Threads to 8, because FFTW on Mac OS seems to become slow beyond this point.
 2022-05-14 13:18:42   To disable this behaviour, recompile with -DIGNORE_APPLE_FFTW_THREAD_LIMIT
 2022-05-14 13:18:42   OpenMP parts of the code will still run with 20 threads.
 2022-05-14 13:18:42
 2022-05-14 13:18:42   Initialized the base grid:
 2022-05-14 13:18:42     Box length            = 75 Mpc/h
 2022-05-14 13:18:42     n                     = 128
 2022-05-14 13:18:42     dx                    = 0.585938
 2022-05-14 13:18:42   Initialized a zoom region:
 2022-05-14 13:18:42     Subbox length         = 37.5 Mpc/h
 2022-05-14 13:18:42     n                     = 128
 2022-05-14 13:18:42     dx                    = 0.292969
 2022-05-14 13:18:42     Zoom factor           = 2
 2022-05-14 13:18:42     Num particles         = 54872
 2022-05-14 13:18:42     Low-left corner in parent grid = (31, 31, 31)
 2022-05-14 13:18:42     Low-left corner (h**-1 Mpc)    = 18.1641, 18.1641, 18.1641
 2022-05-14 13:18:42     Total particles       = 2920232
 2022-05-14 13:18:42   Drawing random numbers (base grid)
  100% |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 2022-05-14 13:18:42   Drawing random numbers (zoom level 1)
  100% |-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
 2022-05-14 13:18:42   Calculating particles from overdensity fields...
 2022-05-14 13:18:42   Combining information from different levels...
 2022-05-14 13:18:43   Writing output; number dm particles=2481256, number gas particles=438976
 2022-05-14 13:18:43   Particles by gadget type:
 2022-05-14 13:18:43      Particle type 0: 438976 particles
 2022-05-14 13:18:43      Particle type 1: 438976 particles
 2022-05-14 13:18:43      Particle type 5: 2042280 particles
 2022-05-14 13:18:43   Using fixed-mass gadget format
 2022-05-14 13:18:43   Finished writing initial conditions

[robmost]

I'm sorry, it does work as you mentioned. I was using the wrong parameter file, one with no gas activated.

On a related note, I have a question about the setup of the gas particles. I see that gas particles in genetIC ICs share initial positions with high-resolution DM particles, whereas in MUSIC they appear to be shifted considerably from the high-resolution DM particles (although both share the same transfer function). Is that the intended behaviour?

[apontzen]

Great, I will merge this change.

Yes it's intentional, we did some tests on this and found it made no difference. However it would not be very hard to shift them half a grid cell if needed (I think that's what MUSIC does if I remember correctly).

[robmost]

Perfect. Thanks for the help!