Given the updated file structuring for material parameters O2permeation.json, AApermeation.json, H2Opermeation.json. We should take a look at how these can be implemented into Scenarios so users can select a single material without digging through the files manually, this wouldn't work nicely for our traditional functional approach and is counter-productive for scenarios.
Now that we are using arbitrary keys such as OX002, the json keys do not correspond to the same materials,
For example
W002 contains water permeation parameters for AAA polyamide
OX002 contains oxygen permeation parameters for ST504 (PET1)
There is no way to know which index corresponds to a desired material ahead of time (or if it even exists in the file). Naive: we could linearly search through the files. However, that is generally a bad approach.
Options
Enforce a linear mapping so these integers would correspond to the same material while the alphabetical identifier would correspond to the chemical/molecule. This would result in skipping integers if in each file if we do not have the associated parameters for that material. This would be convenient for the fixes I have made in #114
Disregard the arbitrary indices and create a mapping of material -> material indices in each file. This might add needless complexity.
Convert back to old name based indexing. Instead of OX003, we could just look for EVA in each file. This removes the concern over arbitrary indices.
Outcome
These options should all be considered breaking changes. The first option would be the most elegant but would need to be expressed very clearly in the documentation so users adding materials at runtime or to the repository do not break their material jsons. All of these options are breaking changes for Scenario. They will also break scenario and utility testing. With the growing complexity of PVDeg we should consider the impacts of these changes for future proofing and tech debt.
Given the updated file structuring for material parameters
O2permeation.json,AApermeation.json,H2Opermeation.json. We should take a look at how these can be implemented into Scenarios so users can select a single material without digging through the files manually, this wouldn't work nicely for our traditional functional approach and is counter-productive for scenarios.Now that we are using arbitrary keys such as
OX002, the json keys do not correspond to the same materials,For example
W002contains water permeation parameters for AAA polyamideOX002contains oxygen permeation parameters for ST504 (PET1)There is no way to know which index corresponds to a desired material ahead of time (or if it even exists in the file). Naive: we could linearly search through the files. However, that is generally a bad approach.
Options
OX003, we could just look forEVAin each file. This removes the concern over arbitrary indices.Outcome
These options should all be considered breaking changes. The first option would be the most elegant but would need to be expressed very clearly in the documentation so users adding materials at runtime or to the repository do not break their material jsons. All of these options are breaking changes for
Scenario. They will also breakscenarioandutilitytesting. With the growing complexity ofPVDegwe should consider the impacts of these changes for future proofing and tech debt.