Prolong CSSAIMS test

[danielhollas]

No description provided.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.25%. Comparing base (7291235) to head (7062e02).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #72      +/-   ##
==========================================
+ Coverage   54.86%   55.25%   +0.39%     
==========================================
  Files          42       42              
  Lines        6183     6162      -21     
  Branches      836      832       -4     
==========================================
+ Hits         3392     3405      +13     
+ Misses       2432     2399      -33     
+ Partials      359      358       -1     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[danielhollas]

@yoricklassmann I've prolonged the CSSAIMS test. The good news is it no longer crashes. The bad news is that according to Codecov it still doesn't cover the code path in SelectionModule, and I don't understand why.

I verified this by applying this diff and the test still passes

diff --git a/src/modules/SelectionModule.f90 b/src/modules/SelectionModule.f90
index cb87f03..f3f123e 100644
--- a/src/modules/SelectionModule.f90
+++ b/src/modules/SelectionModule.f90
@@ -111,6 +111,7 @@ contains
 ! 2. Perform selections within those bundles
 ! 3. Convert the results into the original bundle.
       if (glzStoStateSpecific) then
+         error stop 1
 
          allocate (BundleSS(B1%NumStates))
          call fill_state_bundles(B1, BundleSS)

[yoricklassmann]

Test now covers the 4S path.

[yoricklassmann]

Yes CSSAIMS produces a lot of files!! But that is to be expected as it spawns continuously and selects whenever possible. Of course there is the LimitTraj keyword missing that controls the maximum number of TBFs before selection is initiated.

[danielhollas]

Hmm, there are still Nan values in the E.dat file. ☹️

CC @yoricklassmann

[yoricklassmann]

Do you have a clue where FMS_CGVTT is? It is called by the FMS_potentialB but I can't find it anywhere...

[danielhollas]

The code that is calling it is commented out, no?

[yoricklassmann]

You are absolutely correct, not sure why I didn't see that.

[yoricklassmann]

So then my hunch would be that the NaNs are due to the dead TBFs being too plenty and on top of each other so the energy they contribute will overflow at some point. This might also explain why I didn't see any NaNs when I implemented CSSAIMS originally, where the graveyard is always empty.

[yoricklassmann]

Oh my god! The DeadH matrix elements are initialized wrongly... Whenever a new trajectory is added to the graveyard one would need to calculate matrix elements between all dead trajectories, but no that's not what happens. They are simply left uninitialized.

[danielhollas]

Thanks for figuring it out! 🙏 I'll have a closer look next week.

[yoricklassmann]

So I think we can't actually calculate the matrix elements for the trajectories in the graveyard as it stands currently. So what I've done is to initialize the matrix elements between a newcomer to the graveyard and the rest to 0. As you can see this doesn't affect the tests.

[danielhollas]

So I think we can't actually calculate the matrix elements for the trajectories in the graveyard as it stands currently. So what I've done is to initialize the matrix elements between a newcomer to the graveyard and the rest to 0. As you can see this doesn't affect the tests.

That sounds reasonable, thanks! Also thanks for opening #74