Cant get parallel meshing to work in V18.2
 

Sorry if this is a repeat question. I've done some searching, but other questions related to this don't seem to help. I'm using ANSYS V18.2 and can easily get many cores to work in CFX, but when meshing I can't seem to get it to use more than one core. This is frustrating, as I have a pretty robust machine (Dual Xeon 8-core, 96GB RAM). In the task manager, I see the AnsMeshingServer.exe using 5% CPU, and the AnsysWB Module using another 5%.



I've tried a couple of things already. In the "Details of Mesh" under Advanced, there is a "Number of CPUs for Parallel Part Meshing," but that has no effect. Also, under Tools > Options > Meshing > Meshing I can set the number of cores for Meshing Methods and also for Parallel Part Meshing, but these also do not seem to have an effect.


Is there a licensing option for parallel meshing separate from parallel operation of CFX and FEM sims?


Thanks in advance for any useful advice.

Just a quick question how is your geometry is it only one part or multiple parts?
Because as long as I know with one part parallel meshing doesn't work.

I was afraid that this might be the issue - it's just one part. Will it only perform parallel meshing if I partition the domain myself?

Hello Jones

Were you able to resolve this? How do I partition the mesh for parallel meshing?

Thanks

Yes. I can't claim to be an expert on this, but the way I resolved it was to cut up the domain in SolidWorks, where I originally generated the domain. I reassemble the parts into an assembly in SW, and then import the assembly into CFX. Then CFX will process each block individually using a different core for each. If you create the blocks intelligently, then you can use them to provide location-specific sizing control. Further, if you alter meshing parameters that only affect one block, for example face or body sizing, then only that block will need to be remeshed, so grid refinements can also be pretty fast. Natively, the mesher will not force the meshes to match across inter-block connections. I think there may be a way to do this, but I usually just play around with face-sizing controls until I get a size-match that is close enough for me. If the splits are in regions where not much is happening, then it probably doesn't matter if element sizing is similar, but if you have a split in a high-gradient area, then you should take some care to get them close.

I'm no expert either, but I wouldn't mesh the blocks separately if they are one domain if I didn't absolutely have to. Then you will have to use GGI interfaces instead of having a continuous mesh. This will make the solution less accurate, and also take longer, and use more memory to solve. You won't gain much time in the mesh process, and you will likely lose that time solving, setting up the interfaces in Pre, and have a less accurate solution. Not worth it in my opinion.

Question - are the block-interface connections more costly than the boundaries created by partitioning of the solution for parallel processing? I agree - every internal boundary creates additional work and slows down convergence, but I'm not sure what other option there is if we want to use parallel processing. Second, is there another way to achieve parallel processing during the generation of large meshes? I've had some large meshes that took 7 or 8 hours to produce when they were stuck running on a single core. I was able to get a converged solution on that mesh using SST and Gamma-Theta transition modeling in about the same time or less, since I could use 20+ cores to run CFX.

Hi
Thanks for your reply. Although my aim is to mesh it in the mesh component rather than CFX/fluent. But I see what you mean, so can you create separate parts in the mesh component?

Regards

I don't know the answer to that. I've always created the divisions in CAD. If you import the assembly as a single file into ANSYS, then the block-to-block connections are usually automatically created. I've never had to do any additional work in either the mesher or Pre to make the connections. I've always assumed that the block-to-block connections created roughly the same additional work as the partitioner for parallel processing in the solver. I suppose there might be a little extra work to interpolate data if you don't have a node match across boundaries. I think there may be a way to force the node match, but I have not explored that option. For steady solutions, as long as the element sizes are close across the block boundaries, I've never seen anything non-physical show up. When possible, I try to avoid having a block interface break through a high gradient region, but if you start looking at really large jobs that involve complicated surface topologies, it may be quite challenging or undesirable to have the entire body surface in one block.

If evcelica is opposed to this approach, perhaps they can provide alternate approaches for tackling jobs that are impractical or impossible to run on a single core. The challenge that I have run into is that modern computer architectures that are optimized for high speed solving typically have a large number of slower cores. If you can take advantage of all of the cores, then they are faster than their counterparts that have fewer, but higher speed cores. It's trivial to run the flow solvers using parallel processing to take advantage of multiple cores. However, my experience has been that if you give the mesher a single block domain, it will only use a single core, so machines that have fewer, faster cores will excel for meshing. Since I don't really want to use one machine for meshing and another for solving, domain decomposition has been my workaround.

Some of my larger jobs have on the order of 40 million nodes and 120 million cells. Grid generation on a single block was requiring about 7 to 8 hours. If the mesher failed or you were unhappy with the mesh, it was another day to get a new mesh. This was on a machine with a pair of Xeon Silver chips, and 96GB of RAM, but during meshing, just one core was in use by the mesher. Once I had a mesh, I could use something like 20 cores for the solver, and I could get a converged CFX solution using SST and GT transition modeling in less time than the it took to get a mesh.

I hope this helps.

Hi

Thanks for your reply and suggestion.

Sadly I am not too well versed with Ansys to understand your method. I have a domain with some building geometry in them (urban airflow simulation). I aim to generate about 15-20million mesh elements. It takes about 30-40 minutes currently, I just want to speed up with parallel.

I will look up some videos/tutorials online. If you do find some basic tutorial on parallel meshing please share.

Regards

What tool did you use to generate the geometry of the fluid domain? I design those volumes in SolidWorks, and once I have the complete volume defined, I cut it into multiple pieces in SolidWorks, and then put the pieces together as an assembly. I save the assembly, usually as a parasolid, and import that into Ansys. Ansys automatically sees that the different blocks share faces, and creates the connections required for the flow solver to transfer boundary data.

If you generated the volume inside Ansys using DesignModeler or SpaceClaim, I'm not quite sure what tools they give you do dice up a volume. I never use those to generate anything but the simplest of geometries.

Hi

Since my geometry is simple, I used Rhino to model that. I exported that as IGES format and imported into Mesh component (Ansys) and started meshing it. But since I know that meshing only works if you have more than one component, I created the model as a combination of various parts.

Can I share my mesh file with you so that you can have a look?

Regards

Sure, post it.

PFA the link to download the mesh file. Since it was over the upload limit, I am sharing via WeTransfer

https://wetransfer.com/downloads/65a...6194154/591e2c

Thanks

Sorry, I have no experience with bodies generated this way. It has the appearance of being multi-block, but inside the mesher it is treated as a single body, so no connections, and I believe no opportunity to use parallel processing during meshing.

Hmm, can you please send me one of your mesh files? I'll have a look at how you have modelled and try mimicing your method.

Thanks

I think it's the geometry file that you load in to the mesher that you really want, or at least that is the way that I do it. Here's an example of what I do. In the zip file there's a single-block body that I would use as the starting point. Then I cut up the total domain into suitable parts in the CAD tool, SolidWorks for me. I think stick all the parts back together as an assembly in SolidWorks, and save the assembly. I generally use the parasolid (.x_t) format as a transfer format. I've included an example with a 2-block domain, and if you load that into Ansys and open the mesher, you'll see the two blocks, still labeled with the same names I used in SW, and you'll see that Ansys has already created the connections for adjoining faces.

Attachment 80957

Hope this helps.

Hi
Yes, thanks. The parallel meshing works now