Conversation
|
The tests started failing due to compilation error with |
|
Hmm, weird, I'll have a look later today. |
|
This is the actual error
You need to add the new module in the module list in |
Cool, thanks! |
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #85 +/- ##
==========================================
- Coverage 65.49% 64.68% -0.81%
==========================================
Files 42 43 +1
Lines 7511 7617 +106
Branches 979 998 +19
==========================================
+ Hits 4919 4927 +8
- Misses 2198 2293 +95
- Partials 394 397 +3 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
A simple two-state CH3I model potential implemented for XFAIMS calculations. Improvements will probably come later. At the same time, new XFAIMS module was added, currently containing only one subroutine which prints all the parameters when XFAIMS is launched.
A new global variable which controls if XFAIMS is active or not was added. The activation is done in the main dynamics loop in openfms.F90, because all the other functions and modules, such as FMS_SetTimeStep or SpawnModule, are called often multiple times in each step. The reduction of the time step was also messing with the activation and there were two different condition which were determining XFAIMS activity and time step, although they were not fully compatible. Activating XFAIMS in the main look makes everything consistent now. The only disadvantage is that we can only activate it during the main TimeStep. If the activation time is not a multiple of TimeStep and the current time step was reduced, we do not active exactly at the desired time. There is a warning at the moment. Nevertheless, changing the time step of shifting the whole field and the activation time would solve everything, just the user needs to take a minute to do so.
|
All green! 🎉 Btw it would be awesome if as part of this work you could move the xfaims related parameters into the new module and group then into a derived type, similarly to what yorick did with Spawning parameters in #66 |
This commit tries to unify the printing of the parameters in the input in a more human readable way such that the user can see them immediately.
The start of the propagation is not very well/immediatelly visible in the code.
3 participants
I plan to slowly add some basic modifications of XFAIMS and also a simple CH3I model, which allows me to play with it.