rrsettgast
commented
3 years ago Develop a strategy for xml block reuse in integrated tests.
Closed joshua-white closed 2 years ago
rrsettgast
commented
3 years ago Develop a strategy for xml block reuse in integrated tests.
rrsettgast
commented
3 years ago add ability to write out xml file that embeds all the included xml files...etc.
cssherman
commented
2 years ago I threw together a quick script to check whether xml files are linked somewhere in the integrated tests repo, or contains one of the following keywords: base, benchmark, old. I'm not attempting to parse the ats files, so there is chance that additional files are missing. The current orphan files include:
@rrsettgast - any thoughts on our strategy here?
cssherman
commented
2 years ago A good chunk of these are due to me, and illustrate either pygeosx or advanced xml features. I'm not sure if we are able to use these with the tests yet, but it would be great if we could
We now have a large number of XMLs, and I think a few issues could be addressed during a doc-day sprint:
[x] Many XMLs are extremely repetitive. We should more frequently define base XMLs and just include them when creating problem variations.
[x] Many XMLs contain tags that are not actually used and could be removed (e.g. a coupled solver has linear solver options that overload solver options in the sub-solver blocks). It seems we have a habit of copying-and-adding to create new xmls, but never deleting. We should also explore a way to indicate to users which XML tags will be ignored, so novice users don't spend their time adjusting parameters that have no effect.
[x] We should consider uncrustifying XMLs so they have consistent indentation style.
[x] We should enforce a consistent directory organization and symbolic link policy. Right now integrated tests, examples, and benchmarks are handle differently in different components (though there has been a lot of progress recently improving this)
[ ] We should ensure all XMLs are actually used in an integratedTest, etc. so we don't have any "passive" xmls.
I propose we handle this during a doc-day. If everyone takes on 5 to 10 xmls, we can get through this really quickly. It is busy work, but I think it is worth the hassle.