Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manufactured solutions testing with nontrivial geometry #175

Closed
mrhardman opened this issue Jan 3, 2024 · 5 comments · Fixed by #166
Closed

Manufactured solutions testing with nontrivial geometry #175

mrhardman opened this issue Jan 3, 2024 · 5 comments · Fixed by #166

Comments

@mrhardman
Copy link
Collaborator

To perform MMS tests when using general geometry, it makes sense to upgrade the geometric coefficients in the manufactured_solns.jl module to symbolic functions, and to house these symbolic functions in a struct which can be passed around like the old geometry struct within this module.

Is it possible to make a struct of symbolic functions in julia?

@johnomotani Thoughts? What would be your preferred way to tackle this problem?

@mrhardman
Copy link
Collaborator Author

@mrhardman mrhardman linked a pull request Jan 4, 2024 that will close this issue
@mrhardman
Copy link
Collaborator Author

The eventual solution was to use a different abstract type T for all instances in the "symbolic" struct.

@mrhardman
Copy link
Collaborator Author

@johnomotani In the last commit c689137 I added a facility for checking the magnetic geometry. Despite catching some factor or 2 errors I still see obvious O(1) errors in the 1D magnetic mirror MMS test. Suggestions for other tests would be appreciated!

@johnomotani
Copy link
Collaborator

Sorry for being slow to get to this.

The eventual solution was to use a different abstract type T for all instances in the "symbolic" struct.

That sounds sensible. Could also maybe just return a NamedTuple rather than defining a struct explicitly, like

return (rhostar=rhostar, Bzed=Bzed, Bzeta=Bzeta, Bmag=Bmag, bzed=bzed, bzeta=bzeta, dBdz=dBdz, dBdr=dBdr, jacobian=jacobian)

Despite catching some factor or 2 errors I still see obvious O(1) errors in the 1D magnetic mirror MMS test. Suggestions for other tests would be appreciated!

Sorry if this is too simple, don't know what you've tested. Does the test pass if DeltaB = 0? Could you (artificially) set dBdz=0 while keeping the z-variation of Bmag, and then set Bmag=1 but keep non-zero dBdz?

@mrhardman
Copy link
Collaborator Author

The eventual solution was to use a different abstract type T for all instances in the "symbolic" struct.

That sounds sensible. Could also maybe just return a NamedTuple rather than defining a struct explicitly, like

return (rhostar=rhostar, Bzed=Bzed, Bzeta=Bzeta, Bmag=Bmag, bzed=bzed, bzeta=bzeta, dBdz=dBdz, dBdr=dBdr, jacobian=jacobian)

This could be a better option. I think I could have also used Union{mk_float, Tsym}, where Tsym is the basic symbolic type. I was getting errors where I tried to force a single abstract T on all variables, but those which did not have a "variable" were typed to float and not symbolic expressions.

Despite catching some factor or 2 errors I still see obvious O(1) errors in the 1D magnetic mirror MMS test. Suggestions for other tests would be appreciated!

Sorry if this is too simple, don't know what you've tested. Does the test pass if DeltaB = 0? Could you (artificially) set dBdz=0 while keeping the z-variation of Bmag, and then set Bmag=1 but keep non-zero dBdz?

In my last commit I seem to have got the test working with the mirror term in dvpadt, if I use DeltaB = 0.5. It might be that refactoring fixed something, or it might be that there was a CFL condition being violated that reducing DeltaB fixed. Now I just have a problem with the dvperpdt term. By setting dBdz = 0 manually the test passes. It might be another CFL problem, dvperpdt ~ vperp vpa, which could be large for the maximum velocities on grid. However, dvpadt ~ vperp^2, so one would think that if one term works, the other would too from a stability perspective.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants