Iso surface truncated by new "topo" method

During the same run in an external aerodynamics application, I have tried to use the new isoSurfaceTopo method to extract and visualize turbulent structures via Lambda2, which resulted in a troncated iso-surface near the object, as shown in the picture attached (orange is Lambda2 via standard isoSurface and blue Lambda2 via isoSurfaceTopo).

## Reattaching the author to the issue ticket: @Ricky-11 ##

## Reattached image ##

Using regularise off the isoSurface with "topo" method does not get truncated anymore (see picture attached, orange standard method, blue topo method) but the quality isn't better than the standard method and the file size goes from 388MB to 1.1GB.

By Riccardo Rossi on 2019-07-25T09:05:03 (imported from GitLab project)

## Reattached image ##

Also, since the Lambda2 as well as Q isosurfaces wall bounded flows are chronically affected by the near wall noise, making the file size quite hard to handle for large meshes, it would be great to have additional features within the function objects, if not present already, to manipulated the already generated isosurface at runtime.

For example, in this case one would like to clip the surface based on distance from the wall before writing the file to disk.

By Riccardo Rossi on 2019-07-25T09:10:34 (imported from GitLab project)

I'm trying to get a workaround for this as follows:

1 - Compute the wall distance at run time with a coded function object 2 - Write the isoSurface including the wallDistance field 3 - Call a python script via executeCommand function object to clip and replace the isosurface on disk

However, if I use:

codeExecute #{ Info<< "Computing wall distance\n" << endl; #include "wallDist.H" const volScalarField& y = wallDist::New(mesh).y(); #};

I get:

error: name followed by "::" must be a class or namespace name

Is it ok to get some guidance for this in here?

By Riccardo Rossi on 2019-07-25T11:07:17 (imported from GitLab project)

Will have to pass you the @Prashant or need to until I have some time and a machine (earliest next week).

Sounds good. Thanks Mark.

By Riccardo Rossi on 2019-07-25T13:37:26 (imported from GitLab project)

assigned to @mark

Any simple test geometry you would suggest? I need to see what exactly is going on with the filtering of the topo cells. If the original cuts are ok, or degenerate or if the filter is too aggressive. For that I need a manageable model, but one that exhibits things.

This is the only case where I've tested the isoSurfaceTopo, so I don't have another case where I'm sure the same issue will occur.

What do you mean by simple, though, geometrically or from the number of cells/computing time point of view?

By Riccardo Rossi on 2019-07-29T17:56:24 (imported from GitLab project)

Simple, meaning that we'd generate only a few hundred or thousand triangles for the iso-surface. I would like to see if the generated triangles look correct, perhaps checking on a cell level.

Although it appears at first glance that the filtering of the Topo algorithm is throwing too much away, I'm not entirely certain if that is indeed that case. Part of the filtering is to go through the generated surface and remove any stray triangles that do not describe a closed volume. The idea being that an iso-surface contour must enclose a volume, or terminate on a boundary. If there are triangles kicking about that do not enclose a volume, they are rejected. This also means that an enclosed iso-surface that is smaller than the resolution of its enclosing cell should also be removed. The original points-based iso-surface exhibits several of these artifacts.

This was the very first time I've tried the isoSurfaceTopo and had a problem with it, whereas the standard isoSurface method always worked in any case I had to deal with in the past, so I don't have any other particular geometry in mind.

If you want to make sure to replicate the problem I can see if it would be possible to pass you this case, otherwise I would start from a standard external aero case, as the motorbike tutorial.

By Riccardo Rossi on 2019-08-03T15:18:55 (imported from GitLab project)

mentioned in issue #1383 (closed)

By Riccardo Rossi on 2019-08-03T21:08:21 (imported from GitLab project)

I've tested successfully the following code where vorticity magnitude is computed and then used in the isoSurface definition to write the field with it:

`magvorticityIntegral { functionObjectLibs ("libutilityFunctionObjects.so"); type coded; redirectType integral; outputControl timeStep; code #{ const volVectorField& U = mesh().lookupObject("U"); static autoPtr pField;

if(!pField.valid()) { Info << "Creating magVorticity" << nl;

  pField.set
  (
     new volScalarField
     (
        IOobject
        (
           "magVorticity",
           mesh().time().timeName(),
           U.mesh(),
           IOobject::NO_READ,
           IOobject::AUTO_WRITE
        ),
        mag(fvc::curl(U))
     )
  );

}

volScalarField &magVorticity = pField();

magVorticity.checkIn();

magVorticity += mag(fvc::curl(U)); Info << " max Vorticity " << max(magVorticity) << nl; #}; }`

I've then tried to mimic the same code to compute the wall distance instead of vorticity magnitude, but including wallDist.H led already to a bunch of errors.

By Riccardo Rossi on 2019-08-04T06:45:48 (imported from GitLab project)

Any chance to get any hint/direction on this @mark?

By Riccardo Rossi on 2019-08-19T17:00:41 (imported from GitLab project)

Any chance to get any more hint/direction on this @mark?

By Riccardo Rossi on 2019-10-10T17:08:05 (imported from GitLab project)

Sorry, I really haven't had time to look at this. Need a smallish case so we can see exactly what is going wrong where, and of course some time too.

No worries.

I was actually referring to the chance of computing the wall distance and save it with the isosurface.

Shall I open anothe ticket for it to avoid confusion?

By Riccardo Rossi on 2019-10-11T13:21:10 (imported from GitLab project)

We fixed #1508 (closed) to do with isosurface passing through acmi. Guess this is not your problem. However your problem is probably an unhandled situation in the simplification of the cell-local triangles. We'd need a single cell with cell and point values where the simplified surface is empty.

Sounds good @Mattijs.

Beside the issue with the "topo" method, I'm still trying to figure out how to write the wall distance along with the isosurface to cut it afterwards and get a smaller file and better viz.

Also, what's your experience with Lambda2/Q/LambVector? are you able to get a decent surface in terms of size and structure without having the whole surface of the model covered as in the original picture above (orange) by only playing with the threshold?

By Riccardo Rossi on 2019-11-21T11:35:08 (imported from GitLab project)

This is a coded FO to write the walldistance. Haven't run it for a while though.

    wallDist
    {
        libs            ("libutilityFunctionObjects.so");
        type            coded;

        // Name of on-the-fly generated functionObject
        name            wallDist;

        // When to write
        //writeControl    timeStep;
        //writeInterval   1;

        codeInclude
        #{
            #include "wallDist.H"
        #};

        codeExecute
        #{
            const volScalarField& y = wallDist::New(mesh()).y();
            Info<< "Writing wall distance as " << y.name() << endl;
            y.write();
        #};
    }

isoSurface seems to have built-in subsetting using a cellZone: (see Usage in src/sampling/sampledSurface/isoSurface/sampledIsoSurface.H)

   zone myCellZone;

However isoSurfaceTopo does not have this.

I have only run Q on the motorBike and that looked ok (for the iso value I used).

Thanks. I'll give everything a try right ASAP.

By Riccardo Rossi on 2019-11-21T12:36:59 (imported from GitLab project)