Hi Piotr, I think we would still have the issues Freddie and I stated previously.
Since we distribute the source of releases, someone could change the source of v1.4.0 for example, such that it performed differently, but it would still tag the files it produced as being from v1.4.0. I think this would lead to significant confusion. If we embed the source in each output, then appropriate use of diff could identify if it was indeed run using a release, and if not, exactly what had changed. Peter Dr Peter Vincent MSci ARCS DIC PhD Senior Lecturer and EPSRC Early Career Fellow Department of Aeronautics Imperial College London South Kensington London SW7 2AZ email: [email protected]<mailto:[email protected]> web: www.imperial.ac.uk/aeronautics/research/vincentlab/<http://www.imperial.ac.uk/aeronautics/research/vincentlab/> twitter: @Vincent_Lab<https://twitter.com/#!/Vincent_Lab> On 28 Apr 2016, at 07:42, Piotr Prusiński <[email protected]<mailto:[email protected]>> wrote: Hi all, I see all your points and understand how sophisticated the situation is. The idea given by Freddie of putting the source code into the output seems to be the best option, but I'm afraid it can possibly make the comparison even more complicated due to information overflow. Let say, you will make some important step forward and the code become 2.0.0 and that may be attractive to me to reinstall the code, but its performance in some particular application of my interest will drop down. It would be easier to have a clear and trackable versioning system, so I was wondering if at least the main branch of the code (developed by your original team) could have a stamp (hash as suggested by Matthieu) to indicate the version of the code (or particular solver) to make it easier. At the moment, having installed both 1.3.0 and 1.4.0, I can't distinguish the version of the code used in the simulations of the same project simply by checking the output, I need to make my own script for that. Best regards, Piotr Prusiński, M.Sc. Eng. --- Senior CFD Specialist CFD Analysis Group (UZ3) National Centre for Nuclear Research (NCBJ) A. Sołtana 7, PL-05400 Otwock-Świerk phone: +48.222731126 e-mail: [email protected]<mailto:[email protected]> W dniu środa, 27 kwietnia 2016 15:34:21 UTC+2 użytkownik Freddie Witherden napisał: Hi Matthieu, On 27/04/2016 06:13, Masquelet, Matthieu (GE Global Research, US) wrote: > How about storing the git hash and the output of git diff? If you are > on a public branch that might be a good compromise and a valid > reference no? We did consider this a couple of years back. It is a nice idea, but unfortunately gives rise to an annoying number of edge-cases. Firstly, the use my not be running PyFR from an Git checkout. It could be they run python setup.py install and are running it from elsewhere. (One workaround is to add code to setup.py to take a diff there, but there is still no guarantee that setup.py is being run from a checkout.) Secondly, we would need to ensure that we grab both staged and unstaged differences from Git --- otherwise we would miss out on newly added files. This is fiddly and can have unintended consequences (say if you are doing some debugging and leave a 200 MiB profile file in the PyFR directory; now this critter will find itself inside all of your newly minted .pyfrs files.) Thirdly, having a Git hash (+ diff) is no good unless you can find that hash. If the code is never pushed or backed up it is all too easy to lose everything. Hashes also do not hold up well against git rebases; so you can end up thinking you've lost your code when you haven't. There is also a privacy issue. However, this is more around user education than anything else rather than a technical problem. As such my long term preference is to look to getting PyFR to embed its source code in output files. Python knows what it is currently executing and where the code came from. Once you have the source you can then diff it against currently released version of PyFR to get an idea about its genesis. Moreover, once you have the source code you have the source code. It therefore becomes possible to restart simulations and to post-process output files (hence the .pyfrs file becomes largely self-documenting as it embeds the code required to process itself). Regards, Freddie. -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To post to this group, send email to [email protected]<mailto:[email protected]>. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
