Closed pooyan-dadvand closed 7 years ago
I added some extra info, as the milestone and the project
For the GUI, it would be nice to have at least a couple of weeks of testing and bug fixing after the release is ready and compiled, just to check everything is working fine in a stable version.
I've opened an issue in the GiD Interface repository to define the contents of the released problemtype
You can find it HERE
@pooyan-dadvand What timeframe do you have in mind, i.e. when do you want to release the new version?
@pooyan-dadvand The time frame would be also interesting for me in the context of adding our new elements to the StructuralMechanics app. We are currently writing the test for them.
I was thinking of as soon as possible, let say to make de Kratos release branch and then some weeks of testing the GUI Of course this is our first release here in GitHub and any comment on the procedure is welcomed!
@josep-m-carbonell would you please add the SolidMechanicApplication to the project?
@maceligueta DEM application?
@msandre ALE application?
And meshing application?
The DEM application is not using the new GUI based on the CustomLib yet. Is it feasible to provide a different GUI and join it in the same release? ( @jginternational )
Do I understand correctly that the release is the binary that comes with the kratos problem type and runs from GiD? I'm not sure how the GiD interface is for FSI problems, but if this depends on the ALE application then it could be included.
@maceligueta I'm trying to get a clean solution for DEM but... I have no good solutions yet.
I'll try to avoid the 'ghost of the past' like packing one problemtype inside another.
@msandre, as you said, the binary will be the one shipped with GiD. Moreover we will add it to the releases of GitHub. So we can pass it to users who work only on python and don't want to build the Kratos by themselves.
@maceligueta I understand that DEM would be included in the binaries? Am I right? In that case would you please add the corresponding aplications to the project?
about the GUI I agree with @jginternational that a combination of two interfaces would be a source of problem. Is there any part of DEM that work with jsons which can be migrated? It won't be nice to make the release without DEM...
@pooyan-dadvand Did we finally publish the release 5.1?
At this moment we are waiting for the reorganization of structural mechanics. So we have paused the process. I hope we will restart it again soon.
Dear @KratosMultiphysics/team-maintainers:
After the reorganization of the structural mechanics application I think it is time to make a release. So I would suggest to all application managers (whoes applications are in the release project ) to prepare (cleanup, test) their app for the release for this Friday. The list is still open for new applications.
Friday we will create a branch for this release which would be the base for the binary which will be used in GiD interface tests and bug fixes. Note that it is ok to have applications in binary which does not have GUI.
It is important to participate in this binary and have a release version of your application which let you send the binary and a modified python to anyone who wants to run it without compiling it.
I will create the release branch tomorrow morning if the tests pass tonight. Please do not add new features to the master since then.
I still have some PR to close, like #385, I added everything @RiccardoRossi suggested, can we push this?
@loumalouomega I would only worry about bugfixes at this point. New features can always go into the next release.
OK
@loumalouomega on the top of Jordi's comment, i think that your commit is not really affecting the release, since at least for now we will not package the mmg together with our executables
so i would also wait for the release branch to be created and then do the commit (i'll try to review it asap)
Dear @KratosMultiphysics/team-maintainers
This is just a reminder that we have only 9 days to the release and there are different issues open:
@jginternational , we sent you an example of a DEM use case that was generated with the old GUI. You can contact anyone of the @KratosMultiphysics/dem team for help.
About the other apps, somebody should dedicate about half an hour to check that the interface is working good with the Kratos Release 5.1 branch. Brown bombing: @josep-m-carbonell @jcotela @AFranci @maceligueta @ipouplana @marandra @rubenzorrilla @loumalouomega . Just to make sure everyone is aware of the deadline (9 days!).
I am on the list :dancer:
Remember to check everything in developer && release mode
I was just trying the FluidDynamics application (someone asked me for a packed version) in a laptop with Windows 7. I found out that the screen info seems frozen for a long time (50 seconds) with the following text:
| / |
' / __| _` | __| _ \ __|
. \ | ( | | ( |\__ \
_|\_\_| \__,_|\__|\___/ ____/
Multi-Physics 5.0.0-caabede3d
Initializing KratosFluidDynamicsApplication...
Initializing KratosExternalSolversApplication...
Initializing Kratos MeshingApplication...
[Reading Nodes : 1501 nodes read]
[Reading Elements : 6655 elements read] [Type: Element3D4N]
[Reading Conditions : 52 conditions read] [Type: WallCondition3D3N]
[Reading Conditions : 52 conditions read] [Type: WallCondition3D3N]
[Reading Conditions : 1200 conditions read] [Type: WallCondition3D3N]
[Reading Conditions : 96 conditions read] [Type: WallCondition3D3N]
[Total Lines Read : 19936]
It's a very small case, and it actually looks like the code hangs up. It is actually running, but no info is printed on screen, it's probably in a buffer. Is there some way to make it more 'expressive'?
@maceligueta This happends in windows since 2 years ago, at least. I agree, it should flush more frequently
I don't see this behaviour. If you redirect to a file using whatevertorun >> output.log ?
As I understand @maceligueta wants to increment the verbosity. @jcotela is this govern by echo level?
@pooyan-dadvand I think it's a flush problem. It seems to be holding the printed messages in a buffer and release them all together. Anyway, there should be an independent issue for this.
there is a worst problem.
the buffer of c++ and the one of python are separate, so even the flushing does not really help
Riccardo
So you can make a flush of cout when you are writing the results. In this way it is not too slow but response reasonably.
The Project is for have a visual plan. Still steps from yesterday are missing:
and the followings are added:
Dear all, I have published a first version of the release.
You can check it here: https://github.com/KratosMultiphysics/Kratos/releases/tag/v5.1-Beta-1
Please test it and report all errors you find. This release has been made using the https://github.com/KratosMultiphysics/Kratos/commit/7b7cfd16de5684ac9161023ee518cd9bf786d842 commit, so understand that any changes pushed after this has not been included yet.
Please report in separate issues if possible and put them under the 5.1.xx milestone ( as this one ). This way is far easy to track everything
@pooyan-dadvand, you may be right, however if we need to modify all the prints i would take the occasion to use a kratos_print which we can then redirect through the logger
The Project is for have a visual plan. A beta release binary for windows has been created. you can find it in releases section of repository. For today the most important action would be to check the GUI and decide the release and developer features:
for each new feature please:
And following discussions are active:
Hi @pooyan-dadvand and @RiccardoRossi,
I just talked with @lorenzogracia about the possibility of incorporating the DamApplication into the current release, and we think that there are various things to be checked and tests to be performed before doing so. Specially, after the separation of the Solid and Structural applications... Thereby, for the moment, we do not want to incorporate the DamApp. into the release 5.1. Probably for the next version everything will be more stable.
Regards
@pooyan-dadvand I don't know of anybody with experience compiling feast on windows. I just tried compiling a simple fortran program with x86_64-w64-mingw32-gfortran on my ubuntu and it runs on one of our windows machines as long as I compile it with the -static option. I could compile feast by setting CC = x86_64-w64-mingw32-gcc
and F90 = x86_64-w64-mingw32-gfortran
in make.inc, but I don't have kratos on windows to test it.
@msandre I will try to compile it tomorrow and pack it with the next beta release. In the meantime, there is a first release of kratos for windows here: https://github.com/KratosMultiphysics/Kratos/releases/download/v5.1-Beta-1/KratosMultiphysics_5_1_Beta.zip. If it works there then we are good to go.
Do I have to activate any flag to add feast support in kratos or is just adding that lib?
@pooyan Python version will be 3, @jcotela showed me that it was in fact supported by boost 1.58 so no problem at all.
@pooyan-dadvand and @RiccardoRossi, I will follow @ipouplana and step off this release. My application is still not available in the interface anyway, so I will first add it and then incorporate it in the next release.
Ok, I don't think there will be any trouble with compiling the feast after the above modifications to ExternalSolversApplication/custom_external_libraries/FEAST/3.0/src/make.inc. The part I'm not sure of is how to link it with kratos so that it works in windows. The ExternalSolversApplication needs to be compiled with -DINCLUDE_FEAST=ON in the cmake so that the function calls to feast get compiled. Feast depends on libm, gfortran, blas and lapack. Most probably, you have blas and lapack for windows. I don't know the details of how best to add libm and gfortran. When I compiled the dummy fortran program the mingw took care of it for me. If you know how that part can be done, it may be worth a try, otherwise we might have to leave it out of this release since it's beyond my level.
Actions taken:
Priority actions: (mainly for @KratosMultiphysics/structural-mechanics @KratosMultiphysics/fluid-dynamics)
Actions taken:
Problems:
Still there are no feedback from @KratosMultiphysics/structural-mechanics @KratosMultiphysics/fluid-dynamics on following tasks
@pooyan-dadvand DEM application is not finished yet but can be released on time. Remember that this release date is for the executable, but the problemtype will be released with the next GiD developer. We'll still have some time for GUI changes
As I understood, the GiD release is scheduled for this week also, isn't it?
The 13.1.8d version of GiD was released last week. (It's the minimum GiD required version for Kratos, since DEM needs the latest GID updates for writing spheres)
For the @KratosMultiphysics/structural-mechanics the new GUI is not yet tested by us, but this can be done tomorrow. There are is the new CrBeamElement3D2N and the TrussElement3D2N, which are fully tested and are working. I will make a pull request for the new shell elements ShellThickElement3D3N and ShellThinElement3D4N also tested. For both element types the tests are ready.
@pooyan-dadvand: We would like to add the application cases but as I wrote in my mail we do not have the rights to add the figures to the repository right now. How should be proceed here?
Thanks @AndreasWinterstein for your feedback. Actually I need a list of features to be included and excluded from the GUI very soon.
About the elements, if they are the bug fix and checked version of the ones in release branch then you might add them to the release branch.
Problems:
At this moment the binary release will be still for Thursday. Any required bug fix for the GUI will be imposed in a minor release (5.1.1) afterward.
Action for @KratosMultiphysics/structural-mechanics @KratosMultiphysics/fluid-dynamics on following tasks
Thanks to @KratosMultiphysics/structural-mechanics team for the application cases! 👍 🥇
I took a look at the GUI and the have the following questions:
After moving to GitHub and considering that our last release is from last summer. I think that we should plan a new release. I have created a milestone for this release to assign issues related to this release.
As first step it is necessary to know:
A project has been created in order to add/discuss such lists.
Thanks in advance.
@KratosMultiphysics/technical-committee @jginternational