View Issue Details

IDProjectCategoryView StatusLast Update
0001479OpenFOAM[All Projects] Bugpublic2015-11-21 21:37
ReporterGRAUPSAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformIntel64OSRHELOS Version6.4
Product Version 
Fixed in Version 
Summary0001479: non-axis-aligned flow rate monitor in porous zone
DescriptionSometimes the flow-rate face source monitors in openfoam models are not reporting the correct flow-rates (verified through post-processing). I was able to reproduce this problem with a non-axis-aligned simple pipe.

Please find attached a folder with two pipe models. One model has a porous zone, one does not. Both have a constant flow rate at the inlet of 1 kg/s and both have the monitoring plane in the middle of the pipe. I found that the problem only seems to exist when I add a porous zone into the model. The model with the porous zone is reporting half the flow-rate that it should be at the center of the pipe, where the model without the porous zone (the second included model) reports this correctly.

Let me know if you have any questions, and Happy New Year!
Steps To ReproducePlease see the run_openfoam.sh scripts for each case
Additional InformationI have a feeling this might be related to face normals. I assumed that it would have been resolved though by making sure to put phi under the orientedFaces header. That doesn't seem to be the case though.
TagsNo tags attached.

Activities

GRAUPS

2015-01-08 16:52

reporter  

non_aligned_pipes.tar.gz (215,829 bytes)

user4

2015-03-02 12:53

  ~0003940

It seems the faceZones are not oriented correctly across the processor patches and this causes the sum to be incorrect. This could be due to any one of snappyHexMesh, createPatch, reconstructParMesh, decomposePar, createBaffles or renumberMesh. Do you see the same problems running non-parallel?

GRAUPS

2015-03-04 18:49

reporter   ~0003956

Mattijs, thanks for taking a look at this. I did some more testing and isolating, here is a summary of what I modified and uploaded in the porous setup.

1.) Converted everything to serial
2.) Removed reconstructParMesh, decomposePar, createBaffles, and renumberMesh (createBaffles was a placeholder and not really doing anything)
3.) Manually removed 0 sized patches in order to eliminate the createPatch command

After rerunning the new case using the above modifications, the issue remains. The only command left in the list from your previous note is snappyHexMesh. So the problem with faceZones not being oriented properly may be in there.

I attached my modified case, let me know if you need additional troubleshooting. Thanks!

GRAUPS

2015-03-04 18:50

reporter  

porous_pipe_non_aligned_serial.tar.gz (131,803 bytes)

user4

2015-03-12 17:02

  ~0004096

I thought we fixed the snappyHexMesh zone orientation a while ago. I'll check.

GRAUPS

2015-03-16 16:58

reporter   ~0004147

Thanks mattijs for checking, I look forward to a possible resolution.

user4

2015-03-30 16:34

 

normals.png (68,491 bytes)
normals.png (68,491 bytes)

user4

2015-03-30 16:39

  ~0004552

The 'porous' faceZone consists of two parts. These are correctly oriented pointing out of the corresponding cellZone (see normals.png). The problem one is the 'int' faceZone which does not get a consistent orientation.

GRAUPS

2015-03-30 18:12

reporter   ~0004553

I would agree, the inconsistent orientation of the int facezone is likely the cause of the problem. Note, this problem of inconsistent normals only seems to present itself when I add a cell zone to the pipe and put the int faceZone inside the cellZone. If I remove the cellZone and keep everything else the same, the int faceZone gets oriented properly.

So the problem seems to appear in the presence of a cell zone, if that helps narrow it down at all.

user4

2015-04-10 15:14

 

meshRefinementBaffles.C (100,964 bytes)

user4

2015-04-10 15:15

 

meshRefinement.H (37,347 bytes)

user4

2015-04-10 15:16

  ~0004598

The logic was indeed assuming that faceZones were never inside a cellZone. I've uploaded a patched src/mesh/autoMesh/autoHexMesh/meshRefinement/meshRefinement.H and meshRefinementBaffles.C. Could you see if this fixes your problem and doesn't introduce any other ones?

GRAUPS

2015-04-13 16:08

reporter   ~0004609

mattijs, thanks for the patch, I will test in the next couple days and get back to you.

GRAUPS

2015-04-16 22:01

reporter   ~0004613

mattijs, after testing your patch, I confirmed that it fixed the problem I was seeing (face normals on a faceZone inside a cellZone are now consistent). The monitor on the int faceZone now reports the correct values. I tested both in parallel and in serial and didn't observe any notable changes in the results of the simulation or the mesh that was generated. From my end, and for my uses, the patch appears good.

GRAUPS

2015-07-08 15:12

reporter   ~0005053

mattijs, has this/will this patch be incorporated into the OpenFOAM source?

GRAUPS

2015-08-04 21:51

reporter   ~0005197

Henry, Mattijs, can you please push this fix to OpenFOAM-dev? Or is there a reason that it has been left out thus far?

wyldckat

2015-10-25 20:29

updater  

porous_pipe_non_aligned_serial_v2.tar.gz (131,627 bytes)

wyldckat

2015-10-25 20:33

updater  

meshRefinement.H_v2 (37,347 bytes)

wyldckat

2015-10-25 20:34

updater  

meshRefinementBaffles.C_v2 (100,947 bytes)

wyldckat

2015-10-25 20:42

updater   ~0005492

Sorry, the attached files "meshRefinementBaffles.C_v2" and "meshRefinement.H_v2" are Mattijs original attachments adapted to the latest OpenFOAM-dev, along with, the attached case "porous_pipe_non_aligned_serial_v2.tar.gz" that is re-adapted from "porous_pipe_non_aligned_serial.tar.gz" to the latest OpenFOAM-dev. It seems to work as intended with the v2 modifications.

Problem is that I failed to notice sooner that in the OpenFOAM-history repository is another implemented solution that seems to be better that this one. I'll check it out in a few minutes.

wyldckat

2015-10-25 23:03

updater  

meshRefinementBaffles.C_v3 (100,418 bytes)

wyldckat

2015-10-25 23:13

updater   ~0005493

OK, using the attached case "porous_pipe_non_aligned_serial_v2.tar.gz" and the attached file "meshRefinementBaffles.C_v3" for replacing the file "src/mesh/autoMesh/autoHexMesh/meshRefinement/meshRefinementBaffles.C", it seems to work well at least for this case.

These changes are based on commit bc48d5266868407913914c70096d09d6b5585275 from the OpenFOAM-history repository: https://github.com/OpenCFD/OpenFOAM-history/commit/bc48d5266868407913914c70096d09d6b5585275 - Mattijs committed on 15 April with the message "BUG: #1479: faceZone inside cellZone".


I did my best in adapting the changes, because the code in OpenFOAM-history, namely for this library "autoMesh" has several new features and some that are probably still being worked on, which make the code considerably different from the current one in OpenFOAM-dev. The conflicting changes were made based on what Mattijs had attached here on this bug report.

Given that this v3 adaptation isn't 100% safe, this still needs considerable testing. @GRAUPS: Can you test at least with your cases that need this feature, before this is finally committed to OpenFOAM-dev?

GRAUPS

2015-10-26 16:20

reporter   ~0005494

Bruno, thanks, I really appreciate your work on this. I am unfortunately unable to test this immediately, but will in the next couple days here as my time frees up.

GRAUPS

2015-11-02 16:38

reporter   ~0005542

Bruno, sorry for the delay. I should have time today to test this and get back to you. Expect an update within the next day.

GRAUPS

2015-11-03 15:55

reporter   ~0005548

Bruno, I finally had time to test the meshRefinementBaffles.C_v3 patch that you provided. I tested it on a few different models in both serial and parallel and found no problems with it.

If you find it stable enough, can you also push the change to the newly released OpenFOAM 3.0.x as well as dev?

wyldckat

2015-11-03 16:49

updater   ~0005549

GRAUPS, many thanks for taking the time to test this with several cases!
Henry is who has the final word on integrating the v3 proposed patch.

----------

As for a clarification about what I meant in the comment #5493, namely: «The conflicting changes were made based on what Mattijs had attached here on this bug report.»

There were only two ambiguous locations where the code in OpenCFD's History repository is considerably different from the code in the Foundation's Development repository:

First location is shown in the attached image "001.png", which shows:

  1. on the left the changes provided on the bug tracker (the namely the v2 proposition that was based on the first attached code by Mattijs);
  2. on the centre is the current version in the Development repository;
  3. and on the right is the change made based on the code located on the History repository (the v3 proposition). The respective piece of code is shown here: https://github.com/OpenCFD/OpenFOAM-history/commit/bc48d5266868407913914c70096d09d6b5585275#diff-346983d8c32ae91984f813eb4d8c0412L2853

Please note that:

 * The v3 modification is completely based on the code that is part of the history repository.
 * The only detail used from the original file provided in the bug tracker by Mattijs is regarding the actual location of where the fix should be located.
 * There is an additional code modification that is not shown in the commit itself, but the "else if (ownZone == maxZone)" block was removed for v3, based on the existing code on the history repository and that this block can be considered redundant.


The second location is similar to the first location, as shown in the attached image "002.png":

 * The location shown at Github: https://github.com/OpenCFD/OpenFOAM-history/commit/bc48d5266868407913914c70096d09d6b5585275#diff-346983d8c32ae91984f813eb4d8c0412L2911
 * The code in v3 is based on the code present in the History repository.
 * The original file that Mattijs provided was only used for figuring out the actual location where the fix should be implemented.

The code originally placed on the bug report by Mattijs was not used directly in the proposed v3 fix; it was only used as a rough guideline of "where to look for the issues".

wyldckat

2015-11-03 16:50

updater  

001.png (173,840 bytes)
001.png (173,840 bytes)

wyldckat

2015-11-03 16:50

updater  

002.png (179,984 bytes)
002.png (179,984 bytes)

henry

2015-11-03 16:54

manager   ~0005550

I am setting-up OpenFOAM-3.0.x at the moment and when ready will apply these changes to it as well as OpenFOAM-dev.

henry

2015-11-04 11:58

manager   ~0005554

Thanks Bruno.

Resolved in OpenFOAM-3.0.x: commit 2fe3551252d375f33b29046d6733942e88f3a855
Resolved in OpenFOAM-dev: commit 6206280471fa1a1177711a8f6c5869e04c02baf7

henry

2015-11-08 22:39

manager   ~0005587

I have had to revert this changes as it causes problems with the creation of AMI patches.

If you run the propeller tutorials you will see

AMI: Creating addressing and weights between 20196 source faces and 20412 target faces
AMI: Patch source sum(weights) min/max/average = 0.504506, 1.00581, 0.975813
AMI: Patch target sum(weights) min/max/average = 0, 1.0012, 0.966063

and the weight of 0 causes failure. Without the patch

AMI: Creating addressing and weights between 18496 source faces and 18720 target faces
AMI: Patch source sum(weights) min/max/average = 0.984261, 1.01509, 1.00007
AMI: Patch target sum(weights) min/max/average = 0.969379, 1.00121, 0.999945

wyldckat

2015-11-09 08:56

updater   ~0005588

I was afraid and expecting something like this would happen :(
I won't be able to look into this before Friday, in case anyone wants to tackle this in the meantime.

wyldckat

2015-11-16 22:55

updater   ~0005623

My apologies for the time spent with the v3 patch that didn't work as intended.

I'm attaching the v4 proposition, which provides the following two files and respective modifications:

  - "meshRefinement.H_v4" - the change is minimal, namely only the method "freeStandingBaffleFaces()" had its argument "namedSurfaceIndex" renamed to "faceToZone".

  - "meshRefinementBaffles.C_v4" - the changes include what had already been proposed in v3, but it now includes the changes that were missing and that are from the OpenFOAM-history repository. The changes are:

    - In the method "freeStandingBaffleFaces()", it now uses the new "faceToZone" identification, instead of the "namedSurfaceIndex", making the code a bit simpler and faster in this method. This simplifies the identification of what "faceZones" are free-standing. This was copy-pasted from the OpenFOAM-history repository as-is, since it has all of the necessary pieces and it does not have any additional features.

    - In the method "zonify()", several changes were made:

      - Added the list conversion from "namedSurfaceIndex" to "faceToZone". This was one of the important details that was missing in v3.

      - The "Get coupled neighbour cellZone" block was already in v3 and is copy-pasted from the OpenFOAM-history repository.

      - The call to "freeStandingBaffleFaces" was updated accordingly.

      - Debug output added for "freeStanding.obj", which was already in v3.

      - The "Mark zones" block was slightly updated for avoiding name collision. The local variable "faceToZone" was renamed to "faceToConnectedZone".

      - The loops with the comments "Put the faces into the correct zone" and "Set owner as no-flip" have been updated accordingly to the code that in OpenFOAM-history is now in its own method, also named "zonify()". This was where the v3 patch was using v2 as a reference. This issue is now cleared up.
        In order to make this a bit more clearer, have a look at the following locations in the OpenFOAM-history repository, for the latest commit tree:

           - https://github.com/OpenCFD/OpenFOAM-history/blob/412cb0fec86a8ba12da5f9338301cf3c1dfbe0b3/src/mesh/autoMesh/autoHexMesh/meshRefinement/meshRefinementBaffles.C#L4561
           - https://github.com/OpenCFD/OpenFOAM-history/blob/412cb0fec86a8ba12da5f9338301cf3c1dfbe0b3/src/mesh/autoMesh/autoHexMesh/meshRefinement/meshRefinementBaffles.C#L2849

        The detail here is that the content of the method shown in the second link, is unwrapped in the main "zonify" method in the current OpenFOAM-dev: https://github.com/OpenFOAM/OpenFOAM-dev/blob/baa02e6916b9c13fb377d9299566d90e92647dc1/src/mesh/autoMesh/autoHexMesh/meshRefinement/meshRefinementBaffles.C#L3293


Therefore, this v4 proposition is fully based on the OpenFOAM-history repository. Mattijs original attachment here in the bug tracker was no longer used even as a reference, since I've managed to properly understand the implementation that is currently in OpenFOAM-history.


I've tested this v4 proposition with:

  - the previously adapted case "porous_pipe_non_aligned_serial_v2.tar.gz" and the faceZones were oriented accordingly;

  - the tutorial case "incompressible/pimpleDyMFoam/propeller", for which the AMI is now properly mapped:

    - the v3 proposition gave this broken mapping summary:

      AMI: Creating addressing and weights between 20196 source faces and 20412 target faces
      AMI: Patch source sum(weights) min/max/average = 0.504506, 1.00581, 0.975813
      AMI: Patch target sum(weights) min/max/average = 0, 1.0012, 0.966063

    - all other implementations (dev/v2/v4/history) give this mapping summary:

      AMI: Creating addressing and weights between 18496 source faces and 18720 target faces
      AMI: Patch source sum(weights) min/max/average = 0.984261, 1.01509, 1.00007
      AMI: Patch target sum(weights) min/max/average = 0.969379, 1.00121, 0.999945


I still want to do more tests with the v4 proposition, namely to run the tutorial cases that use snappyHexMesh in OpenFOAM 3.0.0/x and then compare with the ones generated with the v4 proposition implemented into OpenFOAM-dev, in order to assess if the meshes are identically or nearly identically generated... and to diagnose those that aren't identical. I'm already attaching the v4 changes as a pre-emptive measure, to avoid this getting lost due to some weird reason (e.g. HD failure).

wyldckat

2015-11-16 22:55

updater  

meshRefinementBaffles.C_v4 (99,526 bytes)

wyldckat

2015-11-16 22:56

updater  

meshRefinement.H_v4 (37,275 bytes)

wyldckat

2015-11-21 17:04

updater  

Report summarizing any differences in meshing between 3.0.0 and dev+v4.txt (5,979 bytes)
3.0.0 (32-bit labels) vs dev (64-bit labels):

compressible/rhoPimpleDyMFoam/annularThermalMixer
  - Same mesh features, but two files stand out as very strange:
    - constant/polyMesh/owner
    - constant/polyMesh/faces
  
  - Oddly enough, the "constant/polyMesh/faceZones" is identical, including the
    flipMaps.
  
  - But according the "log.snappyHexMesh", the meshing had several issues on
    both versions... so it's natural that there are some issues.

  - The critical difference is revealed by a full checkMesh:

        --- 3.0.0
        +++ dev
        -             rotorBlades      540      682  ok (non-closed singly connected) (-0.0375 -0.0375 0.04) (0.0375 0.0375 0.08)
        -       rotorBlades_slave      540      682  ok (non-closed singly connected) (-0.0375 -0.0375 0.04) (0.0375 0.0375 0.08)
        +             rotorBlades      540      640  ok (non-closed singly connected) (-0.0375 -0.0375 0.04) (0.0375 0.0375 0.08)
        +       rotorBlades_slave      540      640  ok (non-closed singly connected) (-0.0375 -0.0375 0.04) (0.0375 0.0375 0.08)

  - Using the filter "Clean To Grid" in ParaView, which removes duplicate
    points, revealed that 640 is the correct number of unique points.
    Therefore, the excess points is actually a bug in 3.0.0!

  - Furthermore, when using the filter "Normal Glyphs" on the surface mesh for
    the patch "rotorBlades", the normals are all well represented when the
    mesh was generated with the v4 patch on OpenFOAM-dev, which didn't happen
    with 3.0.0.


heatTransfer/buoyantBoussinesqSimpleFoam/iglooWithFridges
  - Identical meshes, including points on all digits (ascii, precision 6).


heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater
  - The master mesh has a virtually identical mesh, although:
    - faces, owner, neighour are identical;
    - points are similar (numerical precision related issues)
    - cellZones are identical;
    - the faceZones have different flipmaps... which is what we changed with v4.

  - "bottomAir" has a nearly identical mesh, only the points differ very little
    between them.
  
  - Other regions have a different arrangement of patches, making it a bit
    difficult to assess directly from comparing the files.

  - "constant/cellToRegion" files are identical.
  
  - Full checkMesh for the main mesh and for each region only reveals that the
    point map is different enough to give some small differences in checks.
    For example:
  
        --- 3.0.0
        +++ dev
            All angles in faces OK.
        -    Face flatness (1 = flat, 0 = butterfly) : min = 0.9799881  average = 0.9999923
        +    Face flatness (1 = flat, 0 = butterfly) : min = 0.9797262  average = 0.9999923
            All face flatness OK.
        -    Cell determinant (wellposedness) : minimum: 0.9215865 average: 10.2842
        +    Cell determinant (wellposedness) : minimum: 0.9215865 average: 10.28414
            Cell determinant check OK.
        - ***Concave cells (using face planes) found, number of cells: 944
        -  <<Writing 944 concave cells to set concaveCells
        -    Face interpolation weight : minimum: 0.3264674 average: 0.4792975
        + ***Concave cells (using face planes) found, number of cells: 933
        +  <<Writing 933 concave cells to set concaveCells
        +    Face interpolation weight : minimum: 0.3263706 average: 0.4792962
            Face interpolation weight check OK.
        -    Face volume ratio : minimum: 0.1168785 average: 0.8916654
        +    Face volume ratio : minimum: 0.1167739 average: 0.8916526
            Face volume ratio check OK.

  - Residuals and Courant Numbers all seemed within the same scale of
    numerical differences.


incompressible/pimpleDyMFoam/propeller
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


incompressible/simpleFoam/motorBike
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).

  
incompressible/simpleFoam/rotorDisk
  - Identical meshes, including points on all digits (ascii, precision 6).


incompressible/simpleFoam/turbineSiting
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


incompressible/simpleFoam/windAroundBuildings
  - Identical meshes, including points on all digits (ascii, precision 6).


lagrangian/MPPICFoam/cyclone/
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


mesh/snappyHexMesh/flange
  - Identical meshes, including points on all digits (ascii, precision 6).


multiphase/interDyMFoam/ras/DTCHull
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


multiphase/interDyMFoam/ras/mixerVesselAMI
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).

multiphase/interFoam/ras/DTCHull
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


multiphase/interPhaseChangeDyMFoam/propeller
  - Very hard to compare based on files, since it ran in binary mode by default.
  - Using "foamFormatConvert -constant" revealed the meshes to be identical
    (ascii, precision 12).


multiphase/interPhaseChangeFoam/cavitatingBullet
  - Identical meshes, including points on all digits (ascii, precision 6).

wyldckat

2015-11-21 17:19

updater   ~0005649

@Henry: The check is now completed! snappyHexMesh is operating properly, at least with all of the tutorials! Attached is the file "Report summarizing any differences in meshing between 3.0.0 and dev+v4.txt" that has the full report.

The only tutorial left out from this battery testing was "incompressible/pisoFoam/les/motorBike/", because the case generates a mesh that requires more than 6GB of system RAM, the current limit of my machine at home.

Most of the cases gave either identical meshes or very similar meshes. The only two with substantial differences were:

 - "compressible/rhoPimpleDyMFoam/annularThermalMixer" - The mesh generated with OpenFOAM-dev with the v4 proposition gave a better mesh!
    - Not only the normals on the baffles/patches "rotorBlades.*" were all now uniformly oriented;
    - but it also revealed a bug in OpenFOAM 3.0.0 where it generated duplicate points on these baffles/patches, namely 682 points on 3.0.0 versus 640 on OpenFOAM-dev with v4 proposition.

 - "heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeater" - The master mesh (the one used for creating the regions) has a virtually identical mesh, although:
    - faces, owner, neighour are identical;
    - points are similar (numerical precision related issues)
    - cellZones are identical;
    - the faceZones have different flipmaps... which is what we changed with v4.


The other detail is that I compared OpenFOAM 3.0.0 with 32-bit labels versus OpenFOAM-dev with 64-bit labels (commit baa02e6916b9), and it still gave identical meshes for most of the cases! It is the desired result, but at least this confirms that 64-bit labels are not affecting the mesh generation, or at least not with most of the tutorials.


All of this to say: proposition v4 is now tested and all signs point toward it now working properly and as intended!

Reminder: there are 2 v4 files, both for folder "src/mesh/autoMesh/autoHexMesh/meshRefinement/":

  - meshRefinementBaffles.C_v4
  - meshRefinement.H_v4

GRAUPS

2015-11-21 18:09

reporter   ~0005650

@Bruno @Henry: Thanks so much for your support and hard work! I look forward to the patch being implemented in 3.0.0 and dev!

henry

2015-11-21 21:37

manager   ~0005653

Thanks Bruno.

Resolved in OpenFOAM-dev by commit ccef40cc0a08d117fc9cfc4729401d1d29769059
Resolved in OpenFOAM-3.0.x by commit e48f65e34d9e5f3704129ae0144018ecb62c1db4

Issue History

Date Modified Username Field Change
2015-01-08 16:52 GRAUPS New Issue
2015-01-08 16:52 GRAUPS File Added: non_aligned_pipes.tar.gz
2015-03-02 12:53 user4 Note Added: 0003940
2015-03-04 18:49 GRAUPS Note Added: 0003956
2015-03-04 18:50 GRAUPS File Added: porous_pipe_non_aligned_serial.tar.gz
2015-03-12 17:02 user4 Note Added: 0004096
2015-03-16 16:58 GRAUPS Note Added: 0004147
2015-03-24 00:17 liuhuafei Issue cloned: 0001603
2015-03-30 16:34 user4 File Added: normals.png
2015-03-30 16:39 user4 Note Added: 0004552
2015-03-30 18:12 GRAUPS Note Added: 0004553
2015-04-10 15:14 user4 File Added: meshRefinementBaffles.C
2015-04-10 15:15 user4 File Added: meshRefinement.H
2015-04-10 15:16 user4 Note Added: 0004598
2015-04-13 16:08 GRAUPS Note Added: 0004609
2015-04-16 22:01 GRAUPS Note Added: 0004613
2015-07-08 15:12 GRAUPS Note Added: 0005053
2015-08-04 21:51 GRAUPS Note Added: 0005197
2015-10-25 20:29 wyldckat File Added: porous_pipe_non_aligned_serial_v2.tar.gz
2015-10-25 20:33 wyldckat File Added: meshRefinement.H_v2
2015-10-25 20:34 wyldckat File Added: meshRefinementBaffles.C_v2
2015-10-25 20:42 wyldckat Note Added: 0005492
2015-10-25 23:03 wyldckat File Added: meshRefinementBaffles.C_v3
2015-10-25 23:13 wyldckat Note Added: 0005493
2015-10-26 16:20 GRAUPS Note Added: 0005494
2015-11-02 16:38 GRAUPS Note Added: 0005542
2015-11-03 15:55 GRAUPS Note Added: 0005548
2015-11-03 16:49 wyldckat Note Added: 0005549
2015-11-03 16:50 wyldckat File Added: 001.png
2015-11-03 16:50 wyldckat File Added: 002.png
2015-11-03 16:54 henry Note Added: 0005550
2015-11-04 11:58 henry Note Added: 0005554
2015-11-04 11:58 henry Status new => resolved
2015-11-04 11:58 henry Resolution open => fixed
2015-11-04 11:58 henry Assigned To => henry
2015-11-08 22:39 henry Note Added: 0005587
2015-11-08 22:39 henry Status resolved => feedback
2015-11-08 22:39 henry Resolution fixed => reopened
2015-11-09 08:56 wyldckat Note Added: 0005588
2015-11-16 22:55 wyldckat Note Added: 0005623
2015-11-16 22:55 wyldckat File Added: meshRefinementBaffles.C_v4
2015-11-16 22:56 wyldckat File Added: meshRefinement.H_v4
2015-11-21 17:04 wyldckat File Added: Report summarizing any differences in meshing between 3.0.0 and dev+v4.txt
2015-11-21 17:19 wyldckat Note Added: 0005649
2015-11-21 17:19 wyldckat Status feedback => assigned
2015-11-21 18:09 GRAUPS Note Added: 0005650
2015-11-21 21:37 henry Note Added: 0005653
2015-11-21 21:37 henry Status assigned => resolved
2015-11-21 21:37 henry Resolution reopened => fixed