macroscopic.epsilon_function(x,y,z) and sigma_function issue: breaks if z dependent about warpx HOT 9 CLOSED

Hi @Poto45, thanks for the reproducer! @RemiLehe volunteered to take it on 🙏

We also added more details on your particle absorber/boundary question, as discussed at IPAC: #4755

@Poto45 , if you don't mind, can you complete your profile under https://github.com/settings/profile a bit more (affiliation & full name)? This helps us not to get too confused between people we meet on GitHub and in person :)

from warpx.

Thanks for reporting this issue.

I am guessing that the problem is indeed with the moving window. My understanding is that, when using the macroscopic properties in WarpX, epsilon and sigma are computed on the grid at t=0 (using this function) but are never updated as the moving window moves. As a consequence, the simulation will always see the epsilon and sigma that were initially in the box, even once the moving window has moved far past the its initial positions.

@RevathiJambunathan Is the above correct? Could we in principle add a function that updates epsilon and sigma, and call it everytime the moving window moves?

from warpx.

@RemiLehe Yes. you are correct. The (epsilon, sigma, mu) are all initialized at t=0. Updating with moving window will potentially solve this issue.

from warpx.

Hello! I wanted to update this page with the case of no moving window. I understand that it was determined that the moving window was the issue, but I wanted to include some figures here for what the results should (probably) look like. Just moving the structure in z was to exemplify the issue, but I'm looking at having a 45 degree cutoff of the structure at the end (with conductor). The warpx script is below with a figure to show what I'm ultimately looking for.
Is there a timeline for this being updated? Is there anything I can do to help?
Thanks!
structure_cutoff.txt

from warpx.

Hi @Poto45,

Thank you for the update!

Yes, we definitely know what to do (description) now. The issue is that the macroscopic quantities are only initialized at t=0 and not continuously in case of a moving window simulation.

I want to apologize that I initially estimated this is a quick fix. With the steps above, we think it is not hard to fix (~1-2 FTE developer days for fix & testing), but with currently a review we have in house, summer vacation coming up for me, and other commitments @RevathiJambunathan, @RemiLehe and I are too oversubscribed just right now to take it on quickly (i.e., likely not before AAC24).

Is there anything I can do to help?

Yes, please let this not discourage you to give it a try in the meantime. @RemiLehe linked the respective function and logic above. Currently this logic is only called once during simulation init.

While this stays the same for the allocations (m_sigma_mf = std::make_unique ...), the value assignment in those "AMReX MultiFabs" (think: fields) should be called every time step (similar how we continuously inject particles in the moving window for plasma background).

Please feel free to modify it, open a "work-in-progress" ([WIP]) pull request so we can help you, and we stay in contact that way and guide you for now?

from warpx.

Sounds great! Thanks! I think for right now, the information I need can be calculated from running the simulation without the moving window, so I might wait until you're able to fix that. If I do decide to try the work around, I'll definitely reach out for help. Thanks again!

from warpx.

@Poto45 Thanks again for reporting this issue.
Would you be able to check whether these changes fix the issue:
#5082

from warpx.

Hi @Poto45, @RemiLehe published a fix in #5082 that we merged into development.

We still want to add an automated test with moving window to ensure this functionality is covered and always works. Do you like to help us design a small (<2 CPU cores, few second runtime) test of that kind that we can run and analyze for correctness in the automated tests of WarpX? :) Does not have to be well resolved or converged, just has to check sensibly that the dependency (x,y,z) works.

from warpx.

@Poto45 confirmed in an email that @5082 fixes the issue.

from warpx.