You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commit 8d3fd55 contain an improved line/surface tracking. The new approach is in two parts and is design to much more robust and correct that previous.
The first part of the issue is SimValid. There are three tests available (via the command line arguments --validCheck --validCell and validPoint. They are combined in the single command line argument --validAll. The purpose of those checks is to determine if cells have (a) missing geometries (b) overlap.
If all the cells in the model are built using a typical CombLayer approach, in that objects which are both FixedComp (or derived classes like FixedRotate) and a ContainedComp. [also FixedGroup/ContainedGroup], then I think there are only four ways that a geometric error can arise: (i) an individual cell can be miss-configured to extend into another cell either outside of the ContainedComp or within the local region. (ii) a cell can be miss configured to leave a gap which is null after the ContainedComp has implaced the region, (iii) the ContainedComp can be miss configured to overlap of miss space, or (iv) the whole object can have not been emplaced in any cell.
There are two checking mechanisms (a) starting from each link point create a set of random line and determine if it meets a problem, and (b) check all the link points and determine if the point is with two or more cells.
Both of these tests caused problems for the line tracker. In particular in the case that the point start on or tracks exactly down a surface. Lets consider the case of testing the number of cells that a point is with when it is on a surface. The first version of the
code allows one surface only and then tested that both cells which were valid could only be satisfied with the surface in opposite directions. This failed at a corner point.
Algorithm
The current method creates a list of all objects that can be valid when a surface is treated as "optimally favourable" to inclusion in the object, if the point is on the surface boundary. Then each object pair is considered in turn and the whole set of possible surface sides
are considered to determine if a pairing exist in which one object is true and then the other object is true as the boolean state of the test surface is flipped.
Result
Test code has been added to testHeadRule::testSurfValid.
The new code allows all the test in all.sh to successfully be executed.
Please comment if this goes wrong -- or you have questions etc.
Still investigating if two non-aligned cubes (so they don't share surfaces) touching on one corner and a surrounding object which
contains both cubes works in all circumstances [in particular if a line travels through the corner).
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Improvement
Commit 8d3fd55 contain an improved line/surface tracking. The new approach is in two parts and is design to much more robust and correct that previous.
The first part of the issue is SimValid. There are three tests available (via the command line arguments --validCheck --validCell and validPoint. They are combined in the single command line argument --validAll. The purpose of those checks is to determine if cells have (a) missing geometries (b) overlap.
If all the cells in the model are built using a typical CombLayer approach, in that objects which are both FixedComp (or derived classes like FixedRotate) and a ContainedComp. [also FixedGroup/ContainedGroup], then I think there are only four ways that a geometric error can arise: (i) an individual cell can be miss-configured to extend into another cell either outside of the ContainedComp or within the local region. (ii) a cell can be miss configured to leave a gap which is null after the ContainedComp has implaced the region, (iii) the ContainedComp can be miss configured to overlap of miss space, or (iv) the whole object can have not been emplaced in any cell.
There are two checking mechanisms (a) starting from each link point create a set of random line and determine if it meets a problem, and (b) check all the link points and determine if the point is with two or more cells.
Both of these tests caused problems for the line tracker. In particular in the case that the point start on or tracks exactly down a surface. Lets consider the case of testing the number of cells that a point is with when it is on a surface. The first version of the
code allows one surface only and then tested that both cells which were valid could only be satisfied with the surface in opposite directions. This failed at a corner point.
Algorithm
The current method creates a list of all objects that can be valid when a surface is treated as "optimally favourable" to inclusion in the object, if the point is on the surface boundary. Then each object pair is considered in turn and the whole set of possible surface sides
are considered to determine if a pairing exist in which one object is true and then the other object is true as the boolean state of the test surface is flipped.
Result
Test code has been added to testHeadRule::testSurfValid.
The new code allows all the test in all.sh to successfully be executed.
Please comment if this goes wrong -- or you have questions etc.
Still investigating if two non-aligned cubes (so they don't share surfaces) touching on one corner and a surrounding object which
contains both cubes works in all circumstances [in particular if a line travels through the corner).
Beta Was this translation helpful? Give feedback.
All reactions