live particle splitting and merging in subdomains - how to handle boundary zones?

[danieljprice]

from @jameswurster: for the particle splitting, we will need to introduce ghost particles for each of the two types of gas particles, where the ghosts will be similar but not identical to boundary particles; one could also see a test where we would want proper boundary particles for each type. To cleanly implement the multiple gas types, and to even clean up the existing boundary types, I wonder what you think about introducing a new integer*1 array where the value is 0 for normal particle, -1 for boundary and -2 for ghost. This would greatly reduce the number of itype's Cons: we get a new array. There may be some difficulty making this backwards compatible, and getting this to work properly in splash. Pro: we naturally allow for boundaries of all particle types, current and future; checking for a boundary particle will require checking only the sign rather than comparing an itype against several possible values; remove the need to calculate ibasetype @becnealon and I are still pondering the cleanest/safest way of implementing live particles splitting/merging. (As I write this, I am really wondering if we should just stick to adding new itypes given the potential issues with backwards compatibility and how many modifications would be required...).

[danieljprice]

@dmentipl suggested a while ago to implement particle subtypes when we were thinking about multigrain dust with different dust sub-types.

The reason subtypes got difficult was that the structure of massoftype and npartoftype would need to change to become two dimensional, i.e. massoftype(itype,isubtype) which would require a LOT of code changes and also to any code that deals with phantom output.

I like the idea of just adding an extra flag for normal/boundary/ghost. It would be backwards compatible since old code just would not read the extra flag and so assume everything is "normal".

There is some code that handles this already, mainly for dust-gas shock tubes with different dust particle types. That is each dust particle type has its own boundary type. These are just implemented as straight types in the iphase array, but they are handled with the "iamboundary" and "iamdust" functions in part.F90 which are just a bit more complicated than the simple (itype=iboundary) flag used previously when there was only one type of boundary particle.

[jameswurster]

I have been following your modifications wrt the boundaries. It won't be hard to follow the current structure by adding the new itypes. I was just thinking if there was a cleaner way. Unlike subtypes, my method would not involve modifying the structure of massoftype or npartoftype, but would have issues with backwards compatibility for simulations that already include boundaries.

We'll continue with the particle splitting, adding new itypes as required.

Thanks for your opinion.

[danieljprice]

For the record, I think the additional array is a good idea for the splitting/merging