View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000744 | OpenFOAM | Bug | public | 2013-02-12 11:46 | 2013-03-14 10:03 |
| Reporter | Assigned To | ||||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Platform | Linux | OS | Other | OS Version | (please specify) |
| Summary | 0000744: sampledSurface plane and cutting plane - moving mesh not updated on VTK output | ||||
| Description | Hello, 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 Reproduce | Add 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-02-12 11:46 |
|
New Issue | |
| 2013-02-16 11:08 | wyldckat | Note Added: 0001921 | |
| 2013-03-14 10:03 |
|
Note Added: 0002003 | |
| 2013-03-14 10:03 |
|
Status | new => resolved |
| 2013-03-14 10:03 |
|
Fixed in Version | => 2.2.x |
| 2013-03-14 10:03 |
|
Resolution | open => fixed |
| 2013-03-14 10:03 |
|
Assigned To | => user4 |
