Re: Galactic Center sims with Phantom

[Daniel Price]

Hi Chris,

The right way would be to add a new integer array in the part module, rather than hacking iphase. A simple way to avoid adding options would be to store this whenever you have particle injection. So in part.F90 you would add a line:

integer :: inject_source(maxpinject)

while in config.F90 you add the lines:

#ifdef INJECT_PARTICLES
maxpinject = maxp
#else
maxpinject = 0
#endif

Likewise, feel free to add an array for the mean molecular weight in part.F90 (probably with a different flag, e.g. “STORE_MEAN_MOL_WEIGHT” and associated maxpmu). This would show up in the cooling function since it would be necessary whenever you convert internal energy to temperature or vice-versa.

Adding these to readwrite_dumps is easy, just add the relevant preprocessor flags and put in the api calls to “write_array” and “read_array” similar to the other arrays.

Hope that helps!

Daniel

> On 14 Nov 2017, at 9:24 am, Christopher Russell <crus...@udel.edu> wrote:
>
> Hi Daniel,
>
> It was great meeting you during your visit to Chile; I hope you had a good trip back home.
>
> There are a couple of things we need to add to Phantom to get the full Galactic center problem running, and some of them would require more coding and changes than what I would feel comfortable making without your permission and/or guidance.
>
> First, we need an integer tag to identify the originating star for each wind particle. The X-ray emissivity for the various WR abundances varies by an order of magnitude, so we need to track whether a wind particle comes from a WC8 star, Ofpe/WN9 star, etc. In the pre-sphNG code of Matthew's that I use, I put this information in the integer array 'ibelong', but I see that is used for MPI decomposition. The name isn't important, obviously, but an integer array needs to be defined and modified every time a particle is injected from star. This integer array also needs to be output in the dump files. Another idea would be to expand the possibilities of iphase: we could use the ones and tens digit to signify a gas/dust/black hole particle (just like it does now), and the hundred and thousands digit to signify the originating star. So iphase(i)=1201 would signify particle i is a gas particle from star 12. This would require the use of modulus's though, which I'm pretty sure are slow, so perhaps that's not the best idea.
>
> Second, which is somewhat related, is using different mean molecular weights for gas particles depending on the star from which it came. Perhaps this only shows up in enforcing the floor temperature since the internal energy is the variable used in the code, or any other call involving 'temperature_coeff', so this might be easy to do. But it would require knowledge of the aforementioned originating-star variable.
>
> The third change is just like the second but for the radiative cooling. I realize that cooling is still being worked out, but the cooling functions for each star also differ, so the originating-star variable determines what cooling rate is called.
>
> If you want me to have a crack at the first change, I imagine I should use pre-processor directives to add in the originating-star integer array as not to slow down other calculations. Then, I could add this to the read and write routines. Does this sound like a good way to go? Or do you have something better in mind?
>
> Thanks,
>
> Chris