I think you should definitely consider issuing a PR for inclusion in yt. That will give the opportunity for review of the code, and also will help us to make sure that there aren't any changes in yt that break the frontend. In general, the barrier to entry for frontends is pretty low (often they get held up by people wanting to implement optional changes, etc). So if you're comfortable with it, I say, go for it!
On Fri, Mar 26, 2021 at 7:10 AM email@example.com wrote:
I'm working on a yt front end for Parthenon, which is a AMR framework we're developing with Los Alamos based on Athena++ but using the Kokkos performance portability library to run on CPUs and GPUs. AthenaPK is our downstream physics code using Parthenon, currently developed at Michigan State University in collaboration with Jim Stone. So far I have a basic frontend based heavily on the existing Athena++ frontend, although some attributes have been renamed and datasets rearranged in Parthenon. We're still working on the yt frontend and changing our output format to better accommodate `yt`, but at some point we would like our frontend to enter the yt code base. What's the typical threshold for inclusion in yt?
Links for Parthenon, AthenaPK, and my WIP frontend https://github.com/lanl/parthenon.git https://gitlab.com/theias/hpc/jmstone/athena-parthenon/athenapk https://github.com/forrestglines/yt/tree/athenapk-frontend
Thanks Forrest _______________________________________________ yt-dev mailing list -- firstname.lastname@example.org To unsubscribe send an email to email@example.com https://mail.python.org/mailman3/lists/yt-dev.python.org/ Member address: firstname.lastname@example.org