Open aprilnovak opened 3 years ago
Yes. We could also sub-iterate, did you try that? Another option is also using a Robin boundary. These are all good things to try.
On Feb 17, 2021, at 2:15 PM, April Novak notifications@github.com<mailto:notifications@github.com> wrote:
For some examples I'm running, if I use too large a time step or too high a thermal conductivity, the nekRS-MOOSE thermal solution diverges - the flux and temperature on the shared surface between these two applications oscillates with growing amplitude. I think this could probably be fixed by incorporating relaxation, which I believe is already supported in the MOOSE framework.
So we should make a test that demonstrates that relaxation is effective, and if not, incorporate some type of relaxation specific to Cardinal.
... copying over from Gitlab
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/neams-th-coe/cardinal/issues/8, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELXDLEICPTUGEQR53Q3MLLS7QIUBANCNFSM4XY5R5OA.
You mean sub-cycle (nekRS dt of 0.1, BISON dt of 0.5)? - we can do that, but from my experience that seems to make the oscillation work for some cases, I think because it allows nekRS and BISON to get more out of sync.
Yes, two heat flux BCs could be another option, but it would take some effort to add that transfer to NekRSProblem
(not impossible, just not there yet).
What I mean in this PR is that it would be great if I could set the temperature BC in BISON as
T = alpha * T_nek, i + (1 - alpha) * T_nek,i-1
so that there's some damping, where alpha
is 0.5, for instance. I think this could be a lot more effective than subcycling in some cases.
I guess in the context of a null transient this makes sense. For a true transient I guess what you really want is extrapolation.
On Feb 17, 2021, at 2:24 PM, April Novak notifications@github.com<mailto:notifications@github.com> wrote:
You mean sub-cycle (nekRS dt of 0.1, BISON dt of 0.5)? - we can do that, but from my experience that seems to make the oscillation work for some cases, I think because it allows nekRS and BISON to get more out of sync.
Yes, two heat flux BCs could be another option, but it would take some effort to add that transfer to NekRSProblem (not impossible, just not there yet).
What I mean in this PR is that it would be great if I could set the temperature BC in BISON as
T = alpha T_nek, i + (1 - alpha) T_nek,i-1
so that there's some damping, where alpha is 0.5, for instance. I think this could be a lot more effective than subcycling in some cases.
— You are receiving this because you commented. Reply to this email directly, view it on GitHubhttps://github.com/neams-th-coe/cardinal/issues/8#issuecomment-780793201, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AELXDLE7CDLSUO6CK3QNWVDS7QJVLANCNFSM4XY5R5OA.
Yes, but I think it could also be used for a transient case with Picard iteration, if we relaxed within the Picard sub-iterations. Anyways, to do that would also require the backup and restore option in #10
For some examples I'm running, if I use too large a time step or too high a thermal conductivity, the nekRS-MOOSE thermal solution diverges - the flux and temperature on the shared surface between these two applications oscillates with growing amplitude. I think this could probably be fixed by incorporating relaxation, which I believe is already supported in the MOOSE framework.
So we should make a test that demonstrates that relaxation is effective, and if not, incorporate some type of relaxation specific to Cardinal.
... copying over from Gitlab