View Issue Details

IDProjectCategoryView StatusLast Update
0001633OpenFOAM[All Projects] Bugpublic2015-05-13 12:38
ReporterSvensenAssigned Tohenry 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
PlatformGNU/LinuxOSUbuntuOS Version14.04
Product Version 
Fixed in Version 
Summary0001633: snappyHexMesh. snap stage generates holes in the mesh
DescriptionOn the snap stage of the snappyHexMesh a lot of warning occurred like:
"FOAM Warning : Displacement (0.000471899 0.000534394 0.000778924) at mesh point 54635 coord (6.23573 -3.19009 12.8464) points through the surrounding patch faces"

As a results the final mesh contains some strange holes... but castellated mesh was OK.
The screenshot is attached.
TagsNo tags attached.

Activities

Svensen

2015-03-24 14:03

reporter  

snappyHexMesh_holes.png (98,921 bytes)
snappyHexMesh_holes.png (98,921 bytes)

user4

2015-03-24 14:18

  ~0004462

snappyHexMesh is warning you that after castellation the normal at a point points through the connected boundary faces. This can happen in complicated geometries where the outside of the castellated mesh is non-manifold or if the mesh has 'bled' into the geometry.

You can run snappyHexMesh in stages and check the result of the castellation phase to see where they're originating from.

Svensen

2015-03-24 15:13

reporter   ~0004464

I've done it step by step, but log of snappyHexMesh doesn't has any warning/errors for the castellated stage. So the problem is in snapping...

user4

2015-03-24 15:19

  ~0004466

You could check the castellated mesh visually (e.g. using paraFoam). Check for non-manifold connectivity on the outside.

Svensen

2015-03-24 15:23

reporter  

snappy_castellated.png (65,225 bytes)
snappy_castellated.png (65,225 bytes)

Svensen

2015-03-24 15:23

reporter  

snappy_castellated1.png (77,020 bytes)
snappy_castellated1.png (77,020 bytes)

Svensen

2015-03-24 15:24

reporter   ~0004468

Visually it's OK and have no errors. (look on the pictures above)

Svensen

2015-03-25 08:22

reporter   ~0004483

I'm not the only one with this problem. For example: http://www.cfd-online.com/Forums/openfoam-meshing-snappyhexmesh/149358-snappyhexmesh-displacement-mesh-point-points-through-surrounding-patch-faces.html

user4

2015-03-25 17:59

  ~0004487

Did you follow the steps as in that discussion? I.e. your mesh is as good as your quality parameters allow so start off with low quality constraints.

2) If you run
    checkMesh -allTopology -allGeometry
on your castellated mesh it will also warn you (running serial only) for non-manifold patches.

Svensen

2015-03-25 22:49

reporter   ~0004488

The output of checkMesh:
Checking geometry...
    Overall domain bounding box (-17 -35.5 -28.75) (18 44.375 10.9375)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-7.90676e-18 -1.50526e-17 -1.91615e-17) OK.
    Max cell openness = 2.96059e-16 OK.
    Max aspect ratio = 2.25 OK.
    Minimum face area = 0.078125. Maximum face area = 2.8125. Face area magnitudes OK.
    Min volume = 0.0439453. Max volume = 2.8125. Total volume = 3686.75. Cell volumes OK.
    Mesh non-orthogonality Max: 40.6286 average: 12.2505
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 1 OK.
    Coupled point location match (average 0) OK.
    Face tets OK.
    Min/max edge length = 0.25 2.25 OK.
  <<Writing 26 near (closer than 9.58129e-05 apart) points to set nearPoints
    All angles in faces OK.
    Face flatness (1 = flat, 0 = butterfly) : min = 1 average = 1
    All face flatness OK.
    Cell determinant (wellposedness) : minimum: 0.720924 average: 12.477
    Cell determinant check OK.
 ***Concave cells (using face planes) found, number of cells: 2359
  <<Writing 2359 concave cells to set concaveCells
    Face interpolation weight : minimum: 0.333333 average: 0.467477
    Face interpolation weight check OK.
    Face volume ratio : minimum: 0.125 average: 0.829253
    Face volume ratio check OK.

Failed 1 mesh checks.

wyldckat

2015-03-26 20:21

updater   ~0004492

Greetings to all!

@Svensen: Since there isn't a test case I can "play" with, I had to rely on a "Sherlock Holmes moment" and examine the provided images in deep detail. This to say that I'm doing a calculated guess, which can only be verified with the case in question or with a small sample of the case being used. At least a biopsy of the geometry would come in handy!? ;)

My deduction based on the images and on the "checkMesh" output is that the base mesh that was possibly created with blockMesh (for the lack of a better expression) is bad for this geometry.
The problem is that instead of having cells that look like "near perfect cubes", the castellated mesh shows a mesh with cells that resemble "elongated bricks". This wouldn't be much of a problem if the geometry was similar enough to said brick-like cells, but in this case, you're witnessing the incorrect collapse of one or both corners of some cells near the walls (although it could also happen with cube-like cells). And it's these cell corners that are possibly being reported by the checkMesh line that ends in "nearPoints".
At least this is what I can figure out without a test case.


The other deduction is somewhat simple: OpenFOAM 2.3.0 is being used. And if the mesh was generated in parallel, I strongly suggest you upgrade to 2.3.1, since this does somewhat look like a bug that might have already been fixed. Which again, could have been easily confirmed with a test case ;)

Best regards,
Bruno

Svensen

2015-03-26 21:18

reporter   ~0004494

The size of test case is bigger then the 2 Mb, so I've uploaded it to the cloud storage: https://yadi.sk/d/vw89bWKbfYZ4B
It contains another aneurysm geometry but have the same problems like in the above pictures. For previous cases I've tried to use cubic cells in background mesh, but it seems that it isn't help. After snap process all of my meshes contains some bad cells.
The mesh was generated in serial.

Svensen

2015-03-28 08:38

reporter   ~0004501

Is it a bug in snappyHexMesh or I simply have done something wrong with snappyHexMeshDict ?

user1112

2015-03-28 12:42

  ~0004502

Last edited: 2015-03-28 12:56

View 3 revisions

Hi,

here is the run with 2.3.x (git version). I only changed blockMeshDict (as suggested by Bruno):
blocks
(
    hex (0 1 2 3 4 5 6 7) (45 25 20) simpleGrading (1 1 1)
);

No errors/warnings are reported by checkMesh:


/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2.3.x |
| \\ / A nd | Web: www.OpenFOAM.org |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : 2.3.x-1449a6736452
Exec : checkMesh
Date : Mar 28 2015
Time : 13:19:44
Host : "....."
PID : 3552
Case : /..../testCase_snap
nProcs : 1
sigFpe : Enabling floating point exception trapping (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster
allowSystemOperations : Allowing user-supplied system call operations

// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time

Create polyMesh for time = 0

Time = 0

Mesh stats
    points: 178685
    faces: 471416
    internal faces: 431853
    cells: 149861
    faces per cell: 6.02738
    boundary patches: 2
    point zones: 0
    face zones: 0
    cell zones: 0

Overall number of cells of each type:
    hexahedra: 121108
    prisms: 10412
    wedges: 0
    pyramids: 0
    tet wedges: 313
    tetrahedra: 7
    polyhedra: 18021
    Breakdown of polyhedra by number of faces:
        faces number of cells
            4 7138
            5 3185
            6 2108
            9 2016
           12 2056
           15 1328
           18 190

Checking topology...
    Boundary definition OK.
    Cell to face addressing OK.
    Point usage OK.
    Upper triangular ordering OK.
    Face vertices OK.
    Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
                   Patch Faces Points Surface topology
             vessel_cube 0 0 ok (empty)
                  flange 39563 46067 ok (closed singly connected)

Checking geometry...
    Overall domain bounding box (-17.6752 -35.0042 -28.8464) (18.0707 43.999 11.1233)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (-4.68144e-17 -1.06821e-16 -8.87313e-18) OK.
    Max cell openness = 4.30541e-16 OK.
    Max aspect ratio = 10.4635 OK.
    Minimum face area = 0.00176546. Maximum face area = 1.13748. Face area magnitudes OK.
    Min volume = 0.000966931. Max volume = 1.14059. Total volume = 3714.38. Cell volumes OK.
    Mesh non-orthogonality Max: 64.9963 average: 12.4419
    Non-orthogonality check OK.
    Face pyramids OK.
    Max skewness = 3.1243 OK.
    Coupled point location match (average 0) OK.

Mesh OK.

End

However the "holes" are still visible. See attached picture.

user1112

2015-03-28 12:43

 

snappy_test.png (174,067 bytes)
snappy_test.png (174,067 bytes)

user1112

2015-03-28 12:56

 

snappy_test_hole.png (11,484 bytes)
snappy_test_hole.png (11,484 bytes)

user1112

2015-03-28 13:12

  ~0004503

Do you use Salome to export stl file?

Svensen

2015-03-28 14:35

reporter   ~0004504

The stl surface was obtained from the clinical data, then I've closed the inlet and outlet holes with netfabb. Netfabb says OK during the surface check.

wyldckat

2015-03-28 17:35

updater  

wyldckat

2015-03-28 17:35

updater  

wyldckat

2015-03-28 17:44

updater   ~0004506

I've attached are 2 images:
 - internal_mesh_polyhedron_foam_vs_OpenFOAM.png
 - surface_mesh_polyhedron_foam_vs_OpenFOAM.png

As the names state, they are representations of the internal and surface meshes, both rendered in their natural polyhedron representation. The data is loaded with the ".foam" (uses the built-in reader in ParaView) and the ".OpenFOAM" (uses the official reader from OpenFOAM for ParaView) file extensions.

In case you haven't deduced yet from these images, the holes you're seeing are actually misrepresentations of the cells for the internal mesh, i.e. they technically don't exist as holes. This is due to a glitch in the ".OpenFOAM" reader which is incorrectly populating some cell representations, for both decomposed and polyhedron representations.

This has been seen in the past a few times, but there hasn't been much effort to try and fix this, since this somewhat rarely occurs. But in the provided model, this is a lot more frequent. I'm going to see if I can extract a "biopsy" of the mesh that has these cells, so that it's easier to diagnose where is the glitch in the source code for the ".OpenFOAM" reader.

user1112

2015-03-28 19:50

  ~0004508

I have done also a test exporting the mesh to fluent. I have done the same cut as in Of and I could see no "holes".

In paraFoam if one selects the walls instead of interior, again no "holes" are to be seen.

wyldckat

2015-03-28 19:59

updater  

before_fix.png (194,140 bytes)
before_fix.png (194,140 bytes)

wyldckat

2015-03-28 19:59

updater  

after_fix.png (191,908 bytes)
after_fix.png (191,908 bytes)

wyldckat

2015-03-28 19:59

updater  

vtkPV4FoamMeshVolume.C_patch (1,047 bytes)

Svensen

2015-03-28 20:03

reporter   ~0004509

So, as I understand the problem of holes in the mesh is caused by some error in OpenFOAM reader plug-in which is distributed with OpenFOAM. I load my snapped mesh with paraview and there are no holes in the internal mesh.
BUT, after that I've tried to make a complete snappyHexMesh process (castellated+snap+addLayers) and after addLayers stage some holes was created (you can see them on the picture that I've attached). The holes are still exist when I open the mesh both in paraFoam and paraview. It seems that there is another bug...

wyldckat

2015-03-28 20:03

updater  

biopsy.tar.gz (7,538 bytes)

Svensen

2015-03-28 20:03

reporter  

snappy_after_addLayers.png (139,332 bytes)
snappy_after_addLayers.png (139,332 bytes)

wyldckat

2015-03-28 20:05

updater   ~0004510

Last edited: 2015-03-28 20:31

View 2 revisions

This was a nice effort, if I may say so myself!
The bug fix provided in the attachment "vtkPV4FoamMeshVolume.C_patch" also fixes the rendering issue that was reported back in Issue #295 http://www.openfoam.org/mantisbt/view.php?id=295 - in the last image "normal_resolution_new_missing_cell.png".

The images "before_fix.png" and "after_fix.png" demonstrate how the provided bug fix resolves this issue.

The attached case "biopsy.tar.gz" has a very small subset mesh that has one of the problem cells that looks like it has a hole.

There is also another cell there that seems problematic... I'll see if I can figure out what's wrong with it. Edit: It's pretty complicated cell formatting issue... I can't figure it out without spending several hours analysing this :(

Svensen

2015-03-28 20:12

reporter   ~0004511

wyldckat, can you apply your patch on OpenFOAM-2.3.x version in git repository ?

What do you think about the holes after addLayers stage ?

wyldckat

2015-03-28 20:22

updater   ~0004512

@Svensen: I don't have permissions to apply to the 2.3.x git repository. But you can easily apply it in your own local repository with the following commands:

  git checkout -b bug1633
  patch -p1 < vtkPV4FoamMeshVolume.C_patch
  git commit -am "applied patch for vtkPV4FoamMeshVolume.C"

When the 2.3.x repository is finally updated, you can do:

  git checkout master
  git pull


The holes you're seeing after the addLayers stage should be the exact same problems I pointed out, namely that the problem is a rendering issue with the ".OpenFOAM" reader. If in the "mesh parts" entry you unselect "internalMesh" and select "flange", you'll no longer see the holes.

Svensen

2015-03-28 20:35

reporter   ~0004513

Last edited: 2015-03-28 20:37

View 2 revisions

Yes, you are right if I select "flange" no holes exists. But the following problem occurs... I've already tried to do some small computation on this mesh (when it have some "rendered" holes). The problem is when you try to post-process your solution, paraview incorrectly apply the velocity field on mesh. For example, in this model the maximum velocity is about 2 m/s. But paraview shows on some "bad" cells the value of velocity is about 8 m/s. It is of course incorrect. That's why you cannot post-process the resulting velocity field in a right way...
So another bug in addLayers stage exists...

Svensen

2015-03-28 20:38

reporter   ~0004514

Last edited: 2015-03-28 20:40

View 2 revisions

About applying patch to the git version of OF-2.3.x. Can we somehow ask henry about this ? Maybe he can apply a patch

wyldckat

2015-03-28 20:38

updater   ~0004515

@Svensen: Once again, I'll need a test case to ascertain what's happening...

Svensen

2015-03-28 20:39

reporter   ~0004516

You are asking about computational results for velocity field ? Am I right ?

wyldckat

2015-03-28 20:44

updater   ~0004517

> You are asking about computational results for velocity field ? Am I right ?

Yes, I was requesting the test case so that I can see the values for myself, because I suspect there is more to it than what you're thinking there is ;)


As for applying the proposed patch on 2.3.x, I think Henry or Mattijs will have to first test this themselves, to double-check if this fixes the issue or not.

henry

2015-03-28 20:51

manager   ~0004518

I will test the patch and push the change if all is well.

Svensen

2015-03-28 20:59

reporter   ~0004519

wyldckat, I have to go away for sometime, I think during a hour I will post a test case with a computational results. Is it OK ?

wyldckat

2015-03-28 21:07

updater   ~0004520

@Svensen: No problem. I'll have a look into it tomorrow.

Svensen

2015-03-28 22:10

reporter  

Svensen

2015-03-28 22:10

reporter  

Svensen

2015-03-28 22:12

reporter   ~0004521

The test case is here: https://yadi.sk/d/jq45O385farc9
Also I've uploaded sample screenshots.

wyldckat

2015-03-29 10:07

updater  

Threshold_Umag.png (151,039 bytes)
Threshold_Umag.png (151,039 bytes)

wyldckat

2015-03-29 10:07

updater  

holes.png (36,601 bytes)
holes.png (36,601 bytes)

wyldckat

2015-03-29 10:12

updater   ~0004522

Last edited: 2015-03-29 10:15

View 2 revisions

@Svensen: The attached file "Threshold_Umag.png" demonstrates that you should apply the "Threshold" filter to the "Cell Data", not to the "Point Data". Therefore, that specific issue isn't a bug.


@Henry and Mattijs: I finally managed to see what they meant by "holes in the mesh", it's now shown clearly in the attached image "holes.png". These appear when using the decomposed polyhedron representation. I'll do another "biopsy" and see if I can figure it out.
Edit: These specific holes appeared in the latest case, namely after adding layers...

henry

2015-03-29 10:28

manager   ~0004523

Are these real "holes" in the mesh or an artifact of the visualization, either a problem with data conversion to ParaView or with the way ParaView handles polys?

wyldckat

2015-03-29 10:43

updater   ~0004524

@Henry: The latest holes are an artifact of the polyhedron decomposition. According to what I'm seeing right now, at least one of the cells has a face on the outside that is convex, which has resulted in having 2 identically overlapping (and very squished) pyramid cells that make up the decomposition of that face. I have yet to figure out if the only difference is in the order of the points.
I'll attach the test case package "biopsy2.tar.gz" in a few minutes.

wyldckat

2015-03-29 10:44

updater  

biopsy2.tar.gz (7,789 bytes)

henry

2015-03-29 10:53

manager   ~0004525

What does it look like if you use the VTKPolyhedron option?

I guess if you run checkMesh with -allGeometry -allTopology it tells you there is a problem with negative volume pyramids.

wyldckat

2015-03-29 11:21

updater   ~0004526

Last edited: 2015-03-29 11:23

View 2 revisions

If we use the VTKPolyhedron option, it's properly represented.

When we use the full checkMesh on the biopsy2 case, these are the major issues:

  <<Writing 2 cells with zero or one non-boundary face to set oneInternalFaceCells
  <<Writing 2 cells with two non-boundary faces to set twoInternalFacesCells

 ***Number of edges not aligned with or perpendicular to non-empty directions: 37
  <<Writing 20 points on non-aligned edges to set nonAlignedEdges

 ***Cells with small determinant (< 0.001) found, number of cells: 5
  <<Writing 5 under-determined cells to set underdeterminedCells


The cell that doesn't represent properly in this small test case is part of "underdeterminedCells". In fact, if I visually decompose this cell, it results in one cell on the surface that has pretty much no thickness and another one that is a reasonable tetrahedra.

If we apply in ParaView the filter "Clean Cells to Grid", it fixes part of the problem, but also removes some additional cells that didn't seem to be a problem in the first place.

--------------------------

Conclusions:

 1- The first proposed fix "vtkPV4FoamMeshVolume.C_patch" is still good to be applied, since it solves the problem with misrepresented tetWedges (test case "biopsy.tar.gz"). Said fix should be applicable to the PV3 reader as well.

 2- If holes start appearing on the mesh's surface, then either: use the filter "Clean Cells to Grid"; or also choose to represent the surface mesh; or use the VTKPolyhedron option. Because such a representation is a symptom of some very bad cells.

Svensen

2015-03-29 12:26

reporter  

high_velocity_cell.png (216,281 bytes)
high_velocity_cell.png (216,281 bytes)

Svensen

2015-03-29 12:27

reporter   ~0004527

Last edited: 2015-03-29 12:29

View 2 revisions

"such a representation is a symptom of some very bad cells", but does snappyHexMesh have to control the quality of the generated mesh with meshQualityDict ? During mesh generation it was no errors...

About the threshold filter, yes it's working well but if you look at screenshot above it's quite strange that there is only ONE cell with high velocity value in the region. It looks some kind of non-realistic.

wyldckat

2015-03-29 12:57

updater  

high_speed_cell.png (19,421 bytes)
high_speed_cell.png (19,421 bytes)

wyldckat

2015-03-29 13:04

updater   ~0004530

@Svensen: The attached image file "high_speed_cell.png" tries to demonstrate the cell that has the very high speed you pointed out in the image "high_velocity_cell.png".

As you might be able to see, the cell is a very complex polyhedral cell, which is very squished and is a very concave in a few directions (I was confused before as to what "convex" actually was :( ). This resulted in "potentialFoam" to have several numerical issues and making this cell have a flow with high velocity.

As for quality control... well, "snappyHexMesh" followed the definitions you gave it in the dictionary file "meshQualityDict". I would suspect that this option:

  minTetQuality 1e-15;

would be one of the responsible parameters for these weird cells. "minVolCollapseRatio" might also be helpful in eliminating such cells. You'll have to try this out yourself.

henry

2015-03-29 20:22

manager   ~0004544

Thanks Bruno for analysing and fixing this.

Resolved by commit a79b45c6115abf706d6d3c0d8fac36e8ffade1c6

Issue History

Date Modified Username Field Change
2015-03-24 14:03 Svensen New Issue
2015-03-24 14:03 Svensen File Added: snappyHexMesh_holes.png
2015-03-24 14:18 user4 Note Added: 0004462
2015-03-24 15:13 Svensen Note Added: 0004464
2015-03-24 15:19 user4 Note Added: 0004466
2015-03-24 15:23 Svensen File Added: snappy_castellated.png
2015-03-24 15:23 Svensen File Added: snappy_castellated1.png
2015-03-24 15:24 Svensen Note Added: 0004468
2015-03-25 08:22 Svensen Note Added: 0004483
2015-03-25 17:59 user4 Note Added: 0004487
2015-03-25 22:49 Svensen Note Added: 0004488
2015-03-26 20:21 wyldckat Note Added: 0004492
2015-03-26 21:18 Svensen Note Added: 0004494
2015-03-28 08:38 Svensen Note Added: 0004501
2015-03-28 12:42 user1112 Note Added: 0004502
2015-03-28 12:43 user1112 File Added: snappy_test.png
2015-03-28 12:50 user1112 Note Edited: 0004502 View Revisions
2015-03-28 12:56 user1112 Note Edited: 0004502 View Revisions
2015-03-28 12:56 user1112 File Added: snappy_test_hole.png
2015-03-28 13:12 user1112 Note Added: 0004503
2015-03-28 14:35 Svensen Note Added: 0004504
2015-03-28 17:35 wyldckat File Added: internal_mesh_polyhedron_foam_vs_OpenFOAM.png
2015-03-28 17:35 wyldckat File Added: surface_mesh_polyhedron_foam_vs_OpenFOAM.png
2015-03-28 17:44 wyldckat Note Added: 0004506
2015-03-28 19:50 user1112 Note Added: 0004508
2015-03-28 19:59 wyldckat File Added: before_fix.png
2015-03-28 19:59 wyldckat File Added: after_fix.png
2015-03-28 19:59 wyldckat File Added: vtkPV4FoamMeshVolume.C_patch
2015-03-28 20:03 Svensen Note Added: 0004509
2015-03-28 20:03 wyldckat File Added: biopsy.tar.gz
2015-03-28 20:03 Svensen File Added: snappy_after_addLayers.png
2015-03-28 20:05 wyldckat Note Added: 0004510
2015-03-28 20:12 Svensen Note Added: 0004511
2015-03-28 20:22 wyldckat Note Added: 0004512
2015-03-28 20:31 wyldckat Note Edited: 0004510 View Revisions
2015-03-28 20:35 Svensen Note Added: 0004513
2015-03-28 20:37 Svensen Note Edited: 0004513 View Revisions
2015-03-28 20:38 Svensen Note Added: 0004514
2015-03-28 20:38 wyldckat Note Added: 0004515
2015-03-28 20:39 Svensen Note Added: 0004516
2015-03-28 20:40 Svensen Note Edited: 0004514 View Revisions
2015-03-28 20:44 wyldckat Note Added: 0004517
2015-03-28 20:51 henry Note Added: 0004518
2015-03-28 20:59 Svensen Note Added: 0004519
2015-03-28 21:07 wyldckat Note Added: 0004520
2015-03-28 22:10 Svensen File Added: addLayers_wrong_velocity_range.png
2015-03-28 22:10 Svensen File Added: addLayers_wrong_velocity_range_threshold.png
2015-03-28 22:12 Svensen Note Added: 0004521
2015-03-29 10:07 wyldckat File Added: Threshold_Umag.png
2015-03-29 10:07 wyldckat File Added: holes.png
2015-03-29 10:12 wyldckat Note Added: 0004522
2015-03-29 10:15 wyldckat Note Edited: 0004522 View Revisions
2015-03-29 10:28 henry Note Added: 0004523
2015-03-29 10:43 wyldckat Note Added: 0004524
2015-03-29 10:44 wyldckat File Added: biopsy2.tar.gz
2015-03-29 10:53 henry Note Added: 0004525
2015-03-29 11:21 wyldckat Note Added: 0004526
2015-03-29 11:23 wyldckat Note Edited: 0004526 View Revisions
2015-03-29 12:26 Svensen File Added: high_velocity_cell.png
2015-03-29 12:27 Svensen Note Added: 0004527
2015-03-29 12:29 Svensen Note Edited: 0004527 View Revisions
2015-03-29 12:57 wyldckat File Added: high_speed_cell.png
2015-03-29 13:04 wyldckat Note Added: 0004530
2015-03-29 20:22 henry Note Added: 0004544
2015-03-29 20:22 henry Status new => resolved
2015-03-29 20:22 henry Resolution open => fixed
2015-03-29 20:22 henry Assigned To => henry