Open antonellozito opened 4 months ago
I was referring to Giovanni Tardini's python code for parsing eqdsk files. But OMFIT does more than this; it also calculates derived quantities. Everything can be replaced; it just takes some effort.
@antonellozito let's wait for a new response from the OMFIT group. If we don't get things moving within the week, I'm in favor of detaching from OMFIT. Your offer to work on that is very much appreciated @antonellozito !
@fsciortino @odstrcilt scraping the internet, I have found that at least the issues in omfit_classes
deriving by using newer versions of Python and Matplotlib might be solved slightly modifying the omfit_classes.utils_math
module (see my latest comment here). In this way, apparently there are no more problems in interfacing with omfit_classes.omfit_eqdsk
, and so the various test scripts in /example work again. Just FYI.
There is some progress with this issue: https://github.com/gafusion/OMFIT-source/pull/7045
@odstrcilt Yes I know, that was my suggestion on how to solve the problem indeed, which another user has implemented as a PR... but apparently it was ignored so far by the Omfit maintainers.
Dear @antonellozito,
I am sorry for not implementing this sooner. I laid out a template for migrating, but I promise that I have had more on my plate than you currently are aware of.
While I totally, respect you and your team's desire to maintain your software, and am fully supportive of you insullating yourself of upstream dependencies, I would encourage you to be more considerate in your postings.
You are not aware of the pressures that are on the other side. You know that what you need is not being done. That is a fact. Asserting that I/we are ignoring you in a public forum is quite a bit more than you can justify. I assure you I have been desparately trying to move OMFIT to python 3.10, Matplotlib beyond 3.5.3 and dying with every day that it is not done, and everyone who knows me can attest to that. All that said, I will continue to try and make sure that we migrate to the latest tools and do my best to get you what you need. I wish you and the AURORA team great success going forward.
Kind regards,
Will
Dear @wdeshazer,
I am also sorry for my previous comment, but I think that there was a misunderstanding caused by a poor wording of mine.
My comment was to be intended as "my suggestion has not been taken up yet my the OMFIT maintainers", in the most neutral sense possible. My poor wording is caused by the fact that, in my native language, the direct equivalent translation of the verb "ignore" can also mean "not be aware of", in the said neutral sense, and not specifically "disregard intentionally" as, apparently, might be received by a native english speaker. I am and was fully aware that the upstream duties are are way beyond the committment needed for a single PR, and I am humbly grateful with your team for this.
Whereas I don't really like being defined as inconsiderate, also in a public forum, for such a simple and, from my side, innocent comment, which was never intended to accuse anyone, I apologize for my poor wording and I hope that this comment clarified the situation.
Best wishes,
Antonello
Since I am currently into the productive mood, @fsciortino @odstrcilt, I mention another issue of the code caused by problems in OMFIT. I already mentioned this here, and I think it is also mentioned in this Aurora PR.
Basically, the OMFIT utility which creates gEQDSK files is broken, following the update to Matplotlib 3.6. This issue is present and known since roughly one year (!!!), but yet not solved. Consquently, if one uses Python 3.11 and the latest Matplotlib, it is not possible to create an Aurora equilibrium starting from some experimental data (e.g. from AUG shotfiles).
IMHO this is a good example which tells why, sometimes, it might be better to be as self-consistent as possible, even at the cost of "re-inventing the wheel" a little bit :) I would suggest that some new functions might be written to create the necessary equilibrium structures for Aurora (starting from data other experimental packages such as, in the case of my interest, aug_sfutils), instead of relying on external packages, especially if they are huge (so inherently slow in solving their own issues). This would definitely make easier solving compatibility issues like the current one.
I might also assign myself as voluntary to do it, but I wanted to hear your opinion first.
EDIT: reading more thoroughly your comments here, I understand that you @odstrcilt are already well aware of this issue... so yes, I assume that you also already have an opinion about whether to possibly detach from the OMFIT ecosystem.