This is the generic ray integration functionality together with an application example in swirl.
The integration is already available in 2D and 3D, while swirl has remained 2D as other mid- and high-level code.
We have not (yet) moved the application code into swirl_user. We don't mind who's going to be doing this. The first step may be to run the code as is and to verify that it's doing exactly what it's supposed to be doing, moving code around afterwards.
The current example code in swirl shows how to compute the intersection between a straight ray and an unmapped 2D forestclaw patch. It switches on the ray coordinate for stability. Currently we do not implement a reliable way to integrate ray segments that are exactly parallel to an edge (in a Cartesian grid). As with all computational geometry, this may need to be made more robust. Temporary (permanent?) workaround is to add a small random number to each ray vector coordinate.
Other examples or applications may use a similar intersection callback. In addition, it would be useful to provide a generic intersection callback capability in forestclaw that honors its (possibly updated) mapping functionality. Both ways may coexist.
I would welcome it if the current intersection callback survives permanently somewhere, if it does not stay in swirl.
What both swirl and any other applications still leave to be desired is to call the ray integration from the time loop. We're completely impartial to how these hooks will be implemented eventually.
Btw. the logging in the swirl example (integrals printed to stderr) needs to be brought up to the desired standard.
This is the generic ray integration functionality together with an application example in swirl. The integration is already available in 2D and 3D, while swirl has remained 2D as other mid- and high-level code. We have not (yet) moved the application code into swirl_user. We don't mind who's going to be doing this. The first step may be to run the code as is and to verify that it's doing exactly what it's supposed to be doing, moving code around afterwards.
The current example code in swirl shows how to compute the intersection between a straight ray and an unmapped 2D forestclaw patch. It switches on the ray coordinate for stability. Currently we do not implement a reliable way to integrate ray segments that are exactly parallel to an edge (in a Cartesian grid). As with all computational geometry, this may need to be made more robust. Temporary (permanent?) workaround is to add a small random number to each ray vector coordinate.
Other examples or applications may use a similar intersection callback. In addition, it would be useful to provide a generic intersection callback capability in forestclaw that honors its (possibly updated) mapping functionality. Both ways may coexist. I would welcome it if the current intersection callback survives permanently somewhere, if it does not stay in swirl.
What both swirl and any other applications still leave to be desired is to call the ray integration from the time loop. We're completely impartial to how these hooks will be implemented eventually.
Btw. the logging in the swirl example (integrals printed to stderr) needs to be brought up to the desired standard.