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

Regarding implementation of implicit thermal conduction in Joule miniapp #4254

Open
Raghavendra0117 opened this issue Apr 19, 2024 · 3 comments

Comments

@Raghavendra0117
Copy link

Dear all,

I am new to MFEM and its usage. Presently, I am interested in solving a simple linear thermal diffusion problem. I have gone through some of the existing examples and miniapps that are already available with MFEM and I found the "joule" miniapp which use mixed FE spaces (L2, RT) suits to my requirement.

I was going through the joule mini app coding to understand the actual discrete eqns that are implemented. Presently, I am only interested in the thermal diffusion part of the "miniapp", neglecting E, B and joule heating (W). I got stuck at the thermal flux solver (--I assume it is an implicit solver--). I tried to derive the corresponding equation implemented in the solver with the help of some comments mentioned in joule.cpp & joule_solver.hpp (at line 85) and I found there are some differences. I have attached my derivations here (please refer to the attached file). Please correct me, if my derivations/assumptions are wrong. Also, It will be of great help If someone can suggest any Literature/docs/reports which describes the governing equations and its discrete form.

Thank you in advance
Raghavendra Kollipara

Attachment:
Thermal_conduction_implicit_formulation.pdf

@Raghavendra0117 Raghavendra0117 changed the title Regarding implicit implementation of thermal conduction in Joule miniapp Regarding implementation of implicit thermal conduction in Joule miniapp Apr 22, 2024
@mlstowell
Copy link
Member

Hi, @Raghavendra0117,
Your derivation appears to be correct but we do something a little different in the joule miniapp. Your derivation assumes the solver will compute $F^{n+1}$ which is quite natural. However, our ODE solvers compute $\frac{\partial F}{\partial t}$ and then use this to compute $F^{n+1}=F^n+dt \frac{\partial F}{\partial t}$ as a separate step. This step is hidden from the miniapp inside the ODE integrator's Step method. This miniapp uses one of MFEM's built in ODE integrators but I believe this time integration scheme follows the more sophisticated schemes offered in SUNDIALS' ARKODE library.

Best wishes,
Mark

@Raghavendra0117
Copy link
Author

Raghavendra0117 commented Apr 24, 2024

Thanks a lot, @mlstowell.

I went through the code related to solver (BackwardEuler in ode.cpp) and this is my understanding so far (pl correct me if i am wrong).

  1. The solver is initialized with oper which is an object of MagneticDiffusionEOperator.
  2. odesolver->step calls implicitsolve method of MagnetiDiffusionEOperator that outputs dX_dt = [dP_dt, dE_dt, dB_dt, dF_dt, dT_dt.]
  3. This dX_dt is used to calculate the x^{n+1} as you mentioned in your comment.

Assuming my understanding is correct, the "implicit solve" routine will return/update dX_dt.

Inside the implicit solve routine, entries of dX_dt is defined as

dT.MakeRef(&L2FESpace, dX_dt,true_offset[0]);
dF.MakeRef(&HDivFESpace, dX_dt,true_offset[1]);

a2->RecoverFEMSolution(X2,v2,F);

weakDiv->AddMult(F, temp_lf, -1.0);

pcg_m3->Mult(temp_lf, dT);
There are no lines related to calculation of dF. Even if one makes thermal flux=0.0 inside the time loop before "odesolver->step()", there is no change in result of thermal flux^{n+1}. Thus, i came to conclusion that F^{n+1} is calculated and same goes to R.H.S of equation related to dT_dt calculation.

I appreciate your help if you can suggest any literature/publications/docs/reports that describes the discrete form of the implemented equations that help my understanding.

Thank you
Raghavendra Kollipara

@mlstowell
Copy link
Member

Hi, @Raghavendra0117,
You've certainly found something odd here. It looks like both E and F are being treated in a non-standard manner. It seems that both of these fields are being solved for directly while dE/dt and dF/dt are both set to zero (so that the X+dt dX/dt step won't alter E and F). My guess is that this is done so that the boundary conditions on E and F can be applied more easily. There will be other ramifications of this choice having to do with the order in which the fields are updated and perhaps other things.

I think we agree that improved documentation is needed here.

Best wishes,
Mark

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

No branches or pull requests

3 participants