Outflow cavity wall setup from Visser et al. (2012)

[space-egret]

This branch contains the customized LIME setup used to model CO emission from UV-heated outflow cavity walls in a low-mass protostar (Visser et al. 2012). I've updated the code as needed to work with the current release of LIME. Though four years old, I hope this setup (or parts of it) is of some use in future applications of LIME.

See README-CAVITYWALLS.md for full details on the custom model.c and on the changes I made to the LIME source code. All commits are squashed together into one, except for some compiler flag changes in the Makefile. Please email me at rvisser@eso.org if you have any questions.

Note that I'm a novice GitHub user and this is my first time issuing a pull request, so I'm sorry if I made any mistakes.

[imckstewart]

Hi, I would not be in favour of merging this as it presently stands, because adding special-case knobs and bells to the code is not a good direction for it to evolve in. What should rather happen is that the code becomes more generic so as to be able to handle as wide as possible a range of physical models.

I admit I have not gone carefully through your PR but a quickish skim this morning seems to indicate that a lot of the bespoke changes are to allow you to generate the rather specialized grid that you need. My view would be that this could better be done externally to Lime. This would need to be coupled with a much simpler and robust way to import grids into the code. I put in a PR #92 (in my other avatar as allegroLeiden 😄) to allow Lime to read/write grid information to FITS at various points in the code. At the developers' telecon we had at the beginning of March people objected to FITS and rather suggested HDF5, and I can see the point of this; but beyond the pure issue of file format I think there is a deeper issue or need to clearly define a grid data model for Lime. I plan to amend my pull request to clarify this further and to decouple the input/output of grid data from the file format employed, so if someone wanted to write an HDF5 backend, that could easily be used as well as or in place of the FITS one. Anyway, the way I envisage this scheme, you would in this environment generate your grid point locations externally, load them into Lime, then sample density etc at all the grid points and proceed from there.

Re the raytracing issue: again I have a PR (#96) to change the algorithm from one oriented on the Voronoi cells (some of which, as you point out, must overlap your density boundary) to one oriented on the Delaunay tetrahedra, which can fairly easily be made not to overlap density boundaries. This would I hope remove the need for your hack to raytrace.

Finally, re the change to the density() interface, why not simply call your temperature() function from within density()?

[space-egret]

Hi Ian,

Understood about not wanting to merge as is. Can you store my branch as a branch within the official LIME repo? What's important to me is simply that my cavity walls setup is preserved somewhere for others to find and use.

Re: the density() interface, what probably happened is that at some point during development, I called density() from temperature(), and therefore couldn't do the reverse anymore. When I removed the density() call from temperature(), apparently it didn't occur to me that I could now remove the `temperature' parameter from the density() function.

Cheers,
Ruud

[smaret]

Thanks @astrochemic for your contribution. I agree with @imckstewart that we can't merge it as it in LIME's master branch.

I understand your point on preserving your version somewhere where other can find it, but I'm not very enthusiastic about having many specific branches of LIME in the official repository. I would suggest that you keep this specific branch into your own GitHub repository, and that you archive it on Zenodo (see this tutorial) and/or the ASCL.

With that said I think it would be nice to maintain a list of papers that/or use LIME (possibly with a link to the specific version of the code used for that work). We could host it on the LIME wiki.