View Issue Details

IDProjectCategoryView StatusLast Update
0000744OpenFOAMBugpublic2013-03-14 10:03
Reporteruser588Assigned Touser4 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformLinuxOSOtherOS Version(please specify)
Summary0000744: sampledSurface plane and cutting plane - moving mesh not updated on VTK output
DescriptionHello,

When running a moving mesh case, like the propeller tutorial, and using a plane or cutting plane function object, i.e.:

functions
{
...
    <foo>
    {
        type surfaces;
        ...
        surfaces
        (
            <bar>
            {
                type <plane|cuttingPlane>;
                ...
            }

then the mesh does not seem to move on the written out vtk slices, although the field values look like they are obeying the moving mesh result.
Steps To ReproduceAdd a plane or cutting plane:

    basePoint (0 0 0);
    normalVector (0 1 0);

to the propeller tut. The mesh in the vtk slices should rotate, it doesn't.

Running moveDynamicMesh (for speed) subsequent timestep vtk files are identical. The same effect has been seem on a real rotating case with p and U fields.
TagsNo tags attached.

Activities

wyldckat

2013-02-16 11:08

updater   ~0001921

After examining some code and the "sampleDict" example at "applications/utilities/postProcessing/sampling/sample/", only a few situations might work accordingly to what you're describing, i.e. moving with the mesh:

  * The "interpolatedPlane" example in the dictionary indicates an entry named "coordinateSystem". This could be extended for being based on a moving coordinate system. But the current implementation at "src/sampling/sampledSurface/sampledPlane/sampledPlane.C" indicates that the position is only calculated when it starts.

  * The "nearWalls_interpolated" example calculates in accordance to a distance to one or more patches. If the patches move, this surface should be able to adjust accordingly, although I have not tested this to confirm.

  * The "triSurfaceSampling" example relies on an STL file for doing the sampling. If this STL file is updated externally along with the case, then I think it should sample as you indicate.

But in the end, all cases seem to be referenced to the initial/global position, unless they refer to something that is truly moving.

user4

2013-03-14 10:03

  ~0002003

This is most likely fixed with the MeshObject fix in

cd124e9745ad9a8b8404c35c643bd21edb25dfeb

I've added sampling to the movingCone pimpleDyMFoam tutorial and it seems to work fine.

Thanks for reporting.

Issue History

Date Modified Username Field Change
2013-02-12 11:46 user588 New Issue
2013-02-16 11:08 wyldckat Note Added: 0001921
2013-03-14 10:03 user4 Note Added: 0002003
2013-03-14 10:03 user4 Status new => resolved
2013-03-14 10:03 user4 Fixed in Version => 2.2.x
2013-03-14 10:03 user4 Resolution open => fixed
2013-03-14 10:03 user4 Assigned To => user4