Open exilief opened 3 weeks ago
Hi!
Regarding the coupling to ViennaPS: Classes that use psDomain (csAtomicLayerProcess
and csMeanFreePath
, you can ignore csSurfaceCellSet
for now) should be decoupled from ViennaPS by just passing the cell-set instead of the whole psDomain.
For the material mapping: I think it's best if ViennaCS uses the material map, which is implemented in ViennaLS, and we wrap around that in ViennaPS. So the materials in ViennaCS are only represented by integers and not an enum.
Since oxideRegrowth
is an example of a process, I think it's best if we leave it in ViennaPS for now.
Ok, I started decoupling some parts (still needs testing), but there is a problem with psMaterial
. The GAS enum value is used as a default value (bulkMaterial
in csSegmentCells
, for example) and changing it to an int like -1 will probably not make sense. If the cell set needs a special "empty" material with a default behavior, could we maybe change the value to 0 instead of 18 and set it as a constant somewhere accessible to the cell set, and assign that value in the PS enum, or is the value 0 already used similarly? Is using -1 (None) okay or is there a better solution?
I also don't know what to do about psLogger
and psUtils
, should their use simply be removed from the cell set?
When changing the material to an int, a few minor changes will also be necessary in psDomain
(casting psMaterial to int), so I think it makes sense to commit the changes to ViennaPS first and then move the cell set outside in a separate step. I made the changes in a fork for now, here.
I ignored the csSurfaceCellSet file, as you suggested.
I changed the psMaterial to int, but in the oxideRegrowth example the gas layer was missing now, because in csDenseCellSet::updateMaterials()
it loops over the level sets, but for the added cover layer it relies on the out-of-bounds default GAS value in psMaterialMap::getMaterialAtIdx()
. I think there is a missing check that should set the coverMaterial
if out of bounds. I solved it by copying what is done in adjustMaterialIds()
, I hope that's correct (it seems overly complicated to do it this way but ok).
if (!cellSetAboveSurface)
--id;
int material = coverMaterial;
if (id >= 0 && id < matMapPtr->getNumberOfLayers())
material = matMapPtr->getMaterialId(id);
So, now only psLogger and psUtils must be replaced/removed (and csSurfaceCellSet). What to do about them?
Hello! I want to start working on moving the cell set into its own library. I will write down some of my thoughts and the decisions that have to be made.
Dependencies:
Coupling to ViennaPS: Some classes are used in the cell set, such as
psMaterial
andpsDomain
. Should some of these be moved to the CS library or replicated there, or should they be replaced with another implementation (like using the wrapped LS functionality directly)? If the exampleoxideRegrowth
is to be moved to the CS library, more functionality used from the PS library (psProcess
) would have to be moved over.Is there anything else we need to be aware of?