SAAMG: Wrong results with elliptic geometry

Summary

The SAAMG solver with elliptic geometry yields wrong results. It behaves like a simulation without space-charge.

SAAMG-FODO.in

Steps to reproduce

Run the attached file with either INTERPL=CONSTANT or INTERPL=LINEAR.

What is the current bug behavior?

The simulation behaves as if space-charge is switched off (FSTYPE = NONE).

added Bug label

changed title from SAAMG: Wrong results with constant interpolation and elliptic geometry to SAAMG: Wrong results with elliptic geometry

changed the description

mentioned in merge request !371 (merged)

created merge request !371 (merged) to address this issue

@frey_m: Once fixed, the input file could be part of a new regression test?

@snuverink_j Sure and maybe also an example for users.

@frey_m Agreed, ideally it would be the same input file to reduce maintenance.

@snuverink_j Definitely.

In that case, it could be added here (list of well documented small regression test input files): https://gitlab.psi.ch/OPAL/src/wikis/RegressionTestExamples

The problem seems to be fixed with a co-moving mesh in longitudinal direction. It also fixes the problem with parallelism. Otherwise one gets weird error message like

Error{0}> 
Error{0}> *** User error detected by function "ParticleSpatialLayout::new_swap_particles"
Error{0}>     could not find node responsible for particle
Error{0}>     could not find node responsible for particle
Error{1}> 
Error{1}> *** User error detected by function "ParticleSpatialLayout::new_swap_particles"
Error{1}>     could not find node responsible for particle
Error{1}>     could not find node responsible for particle

Edited: Copied wrong error message.

@frey_m Just to make sure, having a co-moving frame for the elliptical geometry does not mess with the imported geometry, right? For the imported case, we decided that a co-moving frame was to computationally intensive, as (due to movement and rotations) the intersection points would have to be re-calculated every step.

@winklehner_d Yes, I'm aware of this.

@winklehner_d I changed the code such that the co-moving frame is only applied for EllipticDomain. All other domains are treated the same way as before.

changed milestone to %OPAL 2.4.0

mentioned in issue #119

changed due date to July 24, 2020

@gsell I would say this issue is fixed. But @winklehner_d cannot really verify since the SAAMG seems to be broken generally (ArbitraryDomain ?).

@winklehner_d Could you comment on whether we can stick to the OPAL 2.4.0 milestone?

closed via merge request !371 (merged)

mentioned in commit cccfc5ee