[hjasak]

Dear All,

I had to do some work on topo changes in parallel and there is one IMPORTANT change required with the new svn update. Please pay attention - this WILL break your TOPO CHANGER code.

Due to a possibility that one CPU does do a topo change and another does not, I have introduced a dummy mapPolyMesh and synchronisation across CPUs to deal with it.

The OLD way of signalling no topo change was to put a null pointer inside of autoPtr<mapPolyMesh>

Thus: OLD VARIANT

autoPtr<mapPolyMesh> topoChangeMap = topoChanger_.changeMesh();

bool meshChanged = topoChangeMap.valid();

if (meshChanged)
{

etc.

Now, the pointer will never be NULL, but mapPolyMesh will carry thr information on whether the change happens. The new way of dealing with this is: NEW VARIANT

if (topoChangeMap->morphing())
{

Please keep this in mind: it is important in all cases of topo change.

I will change and keep alive all code components that are checked in; please revisit your local code and ask if there are problems.

Hrv

[Peter_600]

Dear Mr. Jasak,

I am having a problem with topochanger in parallel.
Please see here my problem: http://www.cfd-online.com/Forums/ope...-parallel.html

I am using layering for piston motion and tet automotion solver for the valve movement. For a single processor everything works nicely but in parallel it crashes as soon as a layer will be removed.

Best regards
Peter

[hjasak]

Yes, we have enabled topo changes in parallel about a year ago but there are guidelines and (minor) limitations on what you need to do. Further to that, you will need special domain decomposition and reconstruction tools that deal with parallelism under topo changes.

We currently deal with this under support contracts - please drop me a line and we can discuss what would be appropriate for you.

Hrvoje