I think it’s ok. It would be good to make that explicit to users though, even ones that don’t read the docs. Maybe when loading Enzo-p data, yt could issue a user-visible warning saying that the current Enzo-p output format is not final and yt may not be able to load the file currently being loaded in the future.

It might also be a good idea to have some sort of version number written to disk by Enzo-p so yt could quickly discard data that it can no longer read, along with a messsge suggesting to update Enzo-p.

I think with if we do that it will be clear what our guarantees are. In the future we can remove the warnings and special handling when the Enzo-p output format stabilizes. From then on though I think we’d need to maintain backward compatibility if any changes happen to the Enzo-p output format after it officially stabilizes.

On Tue, May 22, 2018 at 12:51 PM Britton Smith <brittonsmith@gmail.com> wrote:

Hi everyone,

I'm working on adding/updating yt's support for Enzo-P data. If you're unfamiliar, Enzo-P is a totally different data format than Enzo. Enzo-P is still under heavy development, but is approaching the point where it can be used for science. I added an initial frontend last year to support grid data and this open PR adds support for particles and cosmological data sets. This new PR also accommodates changes to the field naming conventions and the ability to get simulation parameters from a libconfig formatted file. Support for these changes is currently implemented a way that respects backward compatibility, which is mostly for the initial sample datasets that accompanied the addition of this frontend.

It is likely that the file format will continue to evolve over the next months as we converge on the best design.  Since this code is still mostly in the development stage, I would prefer to not have to maintain backward compatibility with prior stages of this evolution as there is almost assuredly no data existing in those forms other than the sample data in yt-project.org/data. Trying to do that will only introduce more if statements and confusion in the code.

What I am asking is if I can be allowed to hit the reset button for this frontend and support only the data being produced by the current tip of Enzo-P. This would mean replacing existing sample data, but that would allow me to already make considerable simplifications to the frontend. In addition, I would like to be able to do this once or twice again in the near future as things get finalized, but before the code starts seeing wider public use.

I realize this is a break from our pledge to be backward compatible as much as possible, which is why I'm bringing it up here. If periodically altering the frontend in this way is off limits, then an alternative could be moving Enzo-P support into an external yt extension package until the format is converged. I'm happy to do that, too. I would prefer if the open PR not sit and sit, either being accepted sooner than later with the understanding that things may change or being declined so I can put that functionality elsewhere.

Any thoughts would be appreciated.

Britton

_______________________________________________
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org

_______________________________________________
yt-dev mailing list -- yt-dev@python.org
To unsubscribe send an email to yt-dev-leave@python.org