![]() |
Peano
|
#include <MultiscaleTransitionsTest.h>
Public Member Functions | |
MultiscaleTransitionsTest () | |
virtual void | run () override |
This routine is triggered by the TestCaseCollection. | |
![]() | |
TestCase (const std::string &testCaseName) | |
Constructor. | |
virtual | ~TestCase () |
Destructor. | |
int | getNumberOfErrors () const |
std::string | getTestCaseName () const |
Private Member Functions | |
void | testSievePredicate () |
Test setup from the Swift test case: | |
void | testLiftDropOfParticleAssociatedWithVertex01 () |
Test the instructions indicatring whether to lift a particle. | |
void | testLiftDropOfParticleAssociatedWithVertex02 () |
void | testLiftDropOfParticleAssociatedWithVertex03 () |
void | testLiftDropOfParticleAssociatedWithVertex04 () |
Static Private Attributes | |
static tarch::logging::Log | _log |
Logging device. | |
Additional Inherited Members | |
![]() | |
TestCase ()=delete | |
![]() | |
const std::string | _testCaseName |
Name of the test case. | |
int | _errors |
Error counter. | |
bool | _error |
Indicate within macro if one specific validation failed. | |
Definition at line 16 of file MultiscaleTransitionsTest.h.
toolbox::particles::tests::MultiscaleTransitionsTest::MultiscaleTransitionsTest | ( | ) |
Definition at line 15 of file MultiscaleTransitionsTest.cpp.
|
overridevirtual |
This routine is triggered by the TestCaseCollection.
Implements tarch::tests::TestCase.
Definition at line 162 of file MultiscaleTransitionsTest.cpp.
References testMethod.
|
private |
Test the instructions indicatring whether to lift a particle.
Within the Swift project, I got the following output:
That one is just a tiny little bit too much away from its closest vertex (x-marker._cellCentre=[-0.056386,1.1e-05]) and therefore should be assigned to parent 0.
In the subsequent iteration, it should be dropped again. In a version of the code dated 18/12/23, I was not able to see this drop however. I check the drop behaviour in two steps: I first ensure that the particle is not(!) dropped into the very same vertex again, and then I check that it is indeed dropped into the neighbour vertex.
I depend heavily on the fact that this test is a friend of the vertex marker.
Definition at line 73 of file MultiscaleTransitionsTest.cpp.
References toolbox::particles::dropParticle(), toolbox::particles::liftParticleAssociatedWithVertex(), toolbox::particles::ParticleReassociationInstruction_Keep, and validateWithParams6.
|
private |
Definition at line 170 of file MultiscaleTransitionsTest.cpp.
References toolbox::particles::dropParticle(), toolbox::particles::liftParticleAssociatedWithVertex(), validateWithParams6, and validateWithParams7.
|
private |
Another test from the Swift runs where seven particles disappeared This is the dump of the seven missing particles. We only focus on the first one from hereon: @icode
(HydroPart,[0.944347,0.65799]): ->(moved-while-associated-to-vertex,[0.95,0.66]->x_new,tree=0,trace=substitute-for-whole-trajectory)->(detach-from-vertex,local=1,x=[1,0.666667],h=[0.111111,0.111111],tree=0,trace=UpdateParticleGridAssociation_LiftDrop::__Template_LiftOrReassignParticles)->(assign-to-sieve-set,local=1,tree=0,trace=UpdateParticleGridAssociation_LiftDrop::__Template_LiftOrReassignParticles)
This is due to lifts without the corresponding drops. We can see the following line for the first particle:
so the particle has been local on tree 0 and remote on tree 1, before it started to move. Then it moves and is lifted. We obtain only one drop after that. That drop yields a remote particle on tree 1, i.e. it seems that it is really only dropped on tree 1. And on this tree 1, it is then erased, as it is not local. What we'd like to see is that it is
After studying the setup, it became clear that the sorting per se was correct: The problem here is that the particle should never have ended up on the fine level anyway. If it is there, it should be lifted and counted there, which it is not apparently. So the lift/drop behaves correctly, but the constellation is ill-posed in the first place. If we remove the search radius (as in the implementation of the test), the code shows the correct behaviour.
Once we have assessed the original setup, we therefore return to the large search radius of 0.0555556
Definition at line 228 of file MultiscaleTransitionsTest.cpp.
References toolbox::particles::dropParticle(), toolbox::particles::internal::fitsIntoLevel(), toolbox::particles::liftParticleAssociatedWithVertex(), tarch::la::NUMERICAL_ZERO_DIFFERENCE, toolbox::particles::ParticleReassociationInstruction_Keep, toolbox::particles::ParticleReassociationInstruction_SieveGlobally, toolbox::particles::internal::relativeGrabOwnershipSpatialSortingTolerance(), toolbox::particles::internal::relativeReleaseOwnershipSpatialSortingTolerance(), toolbox::particles::sieveParticle(), validateEqualsWithParams1, validateEqualsWithParams5, validateWithParams1, and validateWithParams5.
|
private |
Another lift/drop test I found the following entry in the database after a particle had disappeared: @icode
(HydroPart,[0.5,0.5]): ->(detach-from-vertex,local=1,x=[0.333333,0.333333],h=[0.333333,0.333333],tree=0,trace=UpdateParticleGridAssociation_BucketSort::__Template_LiftParticles)->(assign-to-sieve-set,local=1,tree=0,trace=UpdateParticleGridAssociation_BucketSort::__Template_LiftParticles) (file:assignmentchecks/TracingAPI.cpp,line:836)
This particle resides exactly in the centre of a cell and seems to be lifted, which contradicts our working assumption that vertices are careful with releasing particles and not aggressive when it comes to grabbing them.
The lift stems from this place:
Funny enough, this particular bug did arise only for two threads, but passed with eight. Digging into the output revealed that the inflying particle seems to not to be local on either rank:
Definition at line 343 of file MultiscaleTransitionsTest.cpp.
References toolbox::particles::internal::fitsIntoLevel(), toolbox::particles::liftParticleAssociatedWithVertex(), tarch::la::NUMERICAL_ZERO_DIFFERENCE, toolbox::particles::ParticleReassociationInstruction_SieveGlobally, toolbox::particles::internal::relativeReleaseOwnershipSpatialSortingTolerance(), toolbox::particles::sieveParticle(), validateEqualsWithParams1, and validateWithParams5.
|
private |
Test setup from the Swift test case:
So it is clear that this sieve should go through. This info is fine, and the unit test simply confirms it. In the test case, this event/message did arise twice when I run the code with two trees. Which is, in principle, fine, given that the vertex of interest might be exactly at the domain boundary.
I would now expect one cell to say "hey, this particle is local here". As particles are associated to vertices, we might to get up to three "no, not here" messages if a vertex is local. These numbers refer to a 2d setup. However, I got
Definition at line 18 of file MultiscaleTransitionsTest.cpp.
References tarch::la::abs(), toolbox::particles::sieveParticle(), and validateWithParams6.
|
staticprivate |
Logging device.
Definition at line 21 of file MultiscaleTransitionsTest.h.