I managed to make T-Flows running simulations with multiple materials in parallel. The algorithm for connecting domains is quite different from sequential one and is described in the header of the subroutine Interface_Mod_Create In order to make it work properly, without any glitches, I had to significantly re-work the routines for sorting real arrays in Sort_Mod. As one could have expected, these sorting routines shouldn't rely on comparing real numbers, but rather checking if they are approximately the same, which we already had in Math_Mod. However, just approximate checking if two real numbers are equal wasn't enough, one also has to extend operators .lt. to work with the same approximate range. This is accomplished by new routine Math_Mod_Smaller_Real. I ran the case 3_Materials with several number of processors, also in debug mode, and found no issues whatsoever. I also ran the (relatively big) case Membrane on 16 processors and it worked like a charm.
In addition to the above changes, I have also moved the case Membrane to Rans directory, since it uses k-eps-zeta-f model in two out of three domains. For this same case, I stored the meshes in .msh format, since the command line option for GMSH wasn't enough for them - they need some recombinations and modifications in input script.
I didn't introduce a test case for multiple materials in the script test_build.sh because it seemed to be too complicated with the current philosophy of the script. For example, to check conversion, we invariantly have one mesh and one script convert.scr. For multimple materials, we have several. So one would have to introduce special case, which seemed ugly. Maybe we should have one entry in the test.sh for mutlimple materials only, not to mingle them with other cases, maybe after Process accuracy test. Or before? I will think of it a bit more.
In any case, I hope you will find no issues with this pull request :-)
Dear Egor,
I managed to make T-Flows running simulations with multiple materials in parallel. The algorithm for connecting domains is quite different from sequential one and is described in the header of the subroutine
Interface_Mod_CreateIn order to make it work properly, without any glitches, I had to significantly re-work the routines for sorting real arrays inSort_Mod. As one could have expected, these sorting routines shouldn't rely on comparing real numbers, but rather checking if they are approximately the same, which we already had inMath_Mod. However, just approximate checking if two real numbers are equal wasn't enough, one also has to extend operators.lt.to work with the same approximate range. This is accomplished by new routineMath_Mod_Smaller_Real. I ran the case3_Materialswith several number of processors, also in debug mode, and found no issues whatsoever. I also ran the (relatively big) caseMembraneon 16 processors and it worked like a charm.In addition to the above changes, I have also moved the case
MembranetoRansdirectory, since it usesk-eps-zeta-fmodel in two out of three domains. For this same case, I stored the meshes in.mshformat, since the command line option forGMSHwasn't enough for them - they need some recombinations and modifications in input script.I didn't introduce a test case for multiple materials in the script
test_build.shbecause it seemed to be too complicated with the current philosophy of the script. For example, to check conversion, we invariantly have one mesh and one scriptconvert.scr. For multimple materials, we have several. So one would have to introduce special case, which seemed ugly. Maybe we should have one entry in thetest.shfor mutlimple materials only, not to mingle them with other cases, maybe afterProcess accuracy test. Or before? I will think of it a bit more.In any case, I hope you will find no issues with this pull request :-)