Leftovers from merge non-relativistic radiation transport: add more output switches, derive IMRadTaskList, etc.
Opened this issue · 7 comments
Mostly from @tomidakn's review that we skipped over to finally merge the monster #492 pull request.
- Derive
IMRadTaskListfromTaskListclass to minimize code duplication (#492 (comment)) - Add new ,
radandradmomtooutputN/variable=possible options e.g. (see https://github.com/PrincetonUniversity/athena/wiki/Outputs). - add some practical usage of the radiation transport and CR transport modules in the Wiki, including outputs and analyses. For example, Brief description of the test codes is helpful for users.
- Remove, rename, and/or cleanup
utils/gauleg.cpp--- can we use or adaptutils/gl_quadrature.cpp?
The function is used when we construct angular grid in 1D for the radiation variable. It takes the user provided total number of angles and determine the values of \cos\theta for each angle and the associated weight for each angle based on GL quadrature.
So 2*nmu is the total number of angles, wmu(i) is the weight for each angle and mu(0,0,0,n1,i) is the cos\theta value for each angle.
Thank you again @yanfeij for all the efforts. I'm trying to use your CR module in a project with my student, and I noticed a few more things.
- CR Boundary conditions. Can we use user-defined physical BC for CR?
- User interface should be consistent with other modules. For example, currently the CR opacity is loaded through pcr->EnrollOpacityFunction in InitUserMeshBlockData, but for other modules we provide interfaces in Mesh. Retrospectively, we could move all the interfaces to each physics module and to be called in InitUserMeshBlockData, but anyway I believe we should provide coherently designed interface.
- Operator splitting mode for CR. This is a long-term topic, but I think it is worth consideration to implement an operator-split integrator for CR as the CR timescale is (and must be) still shorter than the hydrodynamic term. Any thoughts?
Thank you again @yanfeij for all the efforts. I'm trying to use your CR module in a project with my student, and I noticed a few more things.
- CR Boundary conditions. Can we use user-defined physical BC for CR?
- User interface should be consistent with other modules. For example, currently the CR opacity is loaded through pcr->EnrollOpacityFunction in InitUserMeshBlockData, but for other modules we provide interfaces in Mesh. Retrospectively, we could move all the interfaces to each physics module and to be called in InitUserMeshBlockData, but anyway I believe we should provide coherently designed interface.
- Operator splitting mode for CR. This is a long-term topic, but I think it is worth consideration to implement an operator-split integrator for CR as the CR timescale is (and must be) still shorter than the hydrodynamic term. Any thoughts?
Yes, Kengo, you can use user defined boundary condition for CR. Do you mean sub-time step for CR?
I could not find an interface like EnrollCRBoundaryConditions. Can you tell me how to use user-defined BCs for CR?
And yes, I meant subcycling (sub timestep) for CR.
mesh class has EnrollUserCRBoundaryFunction. Have you tried that? It is very similar to EnrollUserBoundaryFunction
I think it will be useful to make it general to create a type of tasks that can run at a different dt. CR could be just one such tasks.
Oh sorry, somehow I missed it. I'll try it.
delaying until after the 24.0 release