Formal I/O tests: we need to be sure that all nodes are correctly stored/restored
This is related to issue #39 (closed) (and #62 (closed))
Some time ago, we noticed that, in particular cases, when we stored a GeoModel tree, then we loaded it and we stored it back, we ended up with a larger number of PhysVol nodes compared to the initial GeoModel tree.
After much investigation I realised that we had two issues:
-
In GeoModelRead, there was a cache to keep track of the nodes that had been restored; the cache was in place to correctly reuse the nodes when they were "shared". The problem was that the cache itself kept track of the number of copies of a given PhysVol node, and that copy-number was used for the cache key. So, in the end, all shared PhysVol nodes were restored as unique node. The issue didn't introduce any error in the GeoModel tree structure itself, the output geometry was correct (the GeoModel tree was, de facto, "flattened", without shared nodes), but the number of nodes and the resulting memory footprint were larger. This has been fixed.
-
After fixing point 1., the number of restored GeoPhys nodes was correct, but the 'read' operation entered in a very long loop that, on given machines, ended up with a crash because they went out of memory. After much investigation, I realised that, while fixing the cache issue, removing the copy number from the cache key introduced a problem in the traversal of the GeoModel tree. When writing back a restored GeoModel tree, the Write action, in fact, visited the shared nodes more than once, creating many more connections than needed. This happened only with the "leaves", the child volumes that did not have other child volumes. And that made the output SQLite file have a larger (HUGE!) number of connections between child volumes, which ended up in "out-of-memory" crashes on some platforms. This has been fixed by introducing a new cache to keep track of the visited volumes while traversing the tree to save the child volumes.
After what we observed for GeoPhysVol nodes and fixed in #39 (closed), I want to be sure that all GeoModel nodes are correctly stored and restored, especially when they are shared.
Therefore, I am setting up some tests to see if the number of nodes are correctly consistent when a GeoModel tree passes through a series of I/O operations.
For that, I created a new test routine, with a number of tests that perform several I/O operations, and a number of tests that prepare ad-hoc GeoModel trees and give them to the tests.
In the following, I detail the routine and the tests I have introduced so far.
New tests can be added later to test additional I/O scenarios.