Replies: 3 comments 7 replies
-
In @KratosMultiphysics/altair we generate a ProjectParameters.json with the settings finally considered (with the defauls set when no defined), we could do that here and add the version that run an specific case. |
Beta Was this translation helpful? Give feedback.
-
Oh I like this idea a lot! I'd also include information about
as well as information about the system Kratos is running on
I'd make this info available in the python layer, and stamp it in every output file that supports writing metadata. It would be a great help for tracking performance across PRs. |
Beta Was this translation helpful? Give feedback.
-
As for external libraries, I suggest copying the entire repo instead of just the important bits. I've already explained why this is necessary in #11795, but I'll write it down here as well for completeness' sake. It'd make our lives easier when debugging, and would promote wider/easier adoption for companies that need to vet the software they're using. Having the entire external library available and providing exact version information about it would save the vetting team a lot of trouble, especially if the company is using the library for other software as well. Furthermore, we should update the overview about the usage of our external libs (is it essential to Kratos; if not, link to instructions on how to disable it, etc...) in the main readme. |
Beta Was this translation helpful? Give feedback.
-
Dear @KratosMultiphysics/all
Several of the teams working on Kratos have asked us to implement some kind of version control / tagging over the files generated to Kratos. In Plain words, to have them marked to know exactly for what version of Kratos were generated.
Piossible example (not final version):
ProjectParameters.json
After discussing in the @KratosMultiphysics/technical-committee we would like to know some insight about:
Beta Was this translation helpful? Give feedback.
All reactions