ViennaTools / ViennaPS

Development repository for ViennaPS, a fully-fledged semiconductor fabrication process simulation library.
https://viennatools.github.io/ViennaPS
Other
18 stars 10 forks source link

ViennaCS Library Extraction #77

Open exilief opened 3 weeks ago

exilief commented 3 weeks ago

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 and psDomain. 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 example oxideRegrowth 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?

tobre1 commented 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.

exilief commented 2 weeks ago

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.

exilief commented 1 week ago

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?