adaptive mesh refinement in parallel runs
Hello,
I have been struggling to use adaptive mesh refinement but I couldn't get it running. I added a dynamicMeshDict to damBreak tutorial at first where it only ran on a single processor. If I decompose the case, it either crashes silently without any error messages or throws a floating point exception with no clear message as to what happened. The same thing happens on my own case on a snappy mesh but crashes in any case. I tried both cases on linux and Linux subsystem for Windows and it's the same (someone suggested it's an I/O issue). checkMesh doesn't report any errors. Do I have to add any other settings than constant/dynamicMeshDict? Any other ideas where to start troubleshooting? |
I cannot speak to the snappy error, as I mostly run it in serial. However, my experience with OF amr is that decomposition method plays a large role in success (or failure) of a run. hierarchical or simple decomposition -- while not necessarily the most efficient -- have proven to be the most stable for me. Additionally, the number of processors also plays a role. The method/number can depend on the case, so it might take some trial and error. I know that others have looked into runTime load balancing to address decomposition method(s)/problems, but that is a whole other problem.
Caelan |
That's regarding parallel cases, but you do run AMR with unstructured meshes successfully? For me even the serial runs don't work.
|
I generally begin with a structured mesh, but have also started with unstructured meshes in the past. Both produced fine results. That said, an unstructured mesh is a consequence of the amr, so you'll be using one anyway.
Caelan |
AMR - Parallel runs
Hi,
I have the same issue, my runs crash at the same increment on parallel. Did you have any joy addressing this? |
All times are GMT -4. The time now is 19:35. |