View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000837 | OpenFOAM | Bug | public | 2013-05-06 19:19 | 2015-02-05 09:20 |
Reporter | Assigned To | henry | |||
Priority | normal | Severity | crash | Reproducibility | always |
Status | closed | Resolution | no change required | ||
Platform | Linux | OS | OpenSUSE | OS Version | 12.2 |
Summary | 0000837: sprayEngineFoam broken with last update to lagrangian | ||||
Description | I was testing a case with sprayEngineFoam with a custom solver based on sprayEngineFoam that crashes on the start of liquid injection. To ensure I wrote my solver properly, I ran the case again with sprayEngineFoam with similar injection parameters. I get the following error: Courant Number mean: 1.02494632e-05 max: 0.00465584598 deltaT = 9.50481277e-09 Crank angle = 349.00043 CA-deg deltaZ = 2.41768611e-08 clearance: 0.0120415656 Piston speed = 2.54364412 m/s Solving cloud sprayCloud --> FOAM FATAL ERROR: Not implemented From function Foam::scalar Foam::liquidProperties::pv(scalar, scalar) const in file liquidProperties/liquidProperties.C at line 230. FOAM aborting #0 Foam::error::printStack(Foam::Ostream&) in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so" #1 Foam::error::abort() in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libOpenFOAM.so" #2 Foam::liquidProperties::pv(double, double) const in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/libliquidProperties.so" #3 Foam::LiquidEvaporation<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > >::TMax(double, double) const in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/lib/liblagrangianSpray.so" #4 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #5 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #6 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #7 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #8 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #9 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #10 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #11 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #12 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #13 in "/home/gandalf/OpenFOAM/OpenFOAM-2.2.x/platforms/linuxGccDPOpt/bin/sprayEngineFoam" #14 __libc_start_main in "/lib/libc.so.6" #15 at /home/abuild/rpmbuild/BUILD/glibc-2.15/csu/../sysdeps/i386/elf/start.S:122 Aborted | ||||
Steps To Reproduce | Run any sprayEngineFoam case with liquid injection | ||||
Additional Information | I have included my sprayCloudProperties, in case there is an issue with the configuration (doubtful as I've cross checked it with the new aachenBomb tutorial). sprayFoam appears to work, so it may be an issue with the engine versions. | ||||
Tags | No tags attached. | ||||
2013-05-06 19:19
|
sprayCloudProperties (4,694 bytes)
/*--------------------------------*- C++ -*----------------------------------*\ | ========= | | | \\ / F ield | OpenFOAM: The Open Source CFD Toolbox | | \\ / O peration | Version: 2.2.0 | | \\ / A nd | Web: www.OpenFOAM.org | | \\/ M anipulation | | \*---------------------------------------------------------------------------*/ FoamFile { version 2.0; format binary; class dictionary; location "constant"; object SprayCloudProperties; } // * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // solution { active true; coupled true; transient yes; cellValueSourceCorrection on; sourceTerms { schemes { rho explicit 1; U explicit 1; Yi explicit 1; h explicit 1; radiation explicit 1; } } interpolationSchemes { rho cell; U cellPoint; thermo:mu cell; T cell; Cp cell; p cell; } integrationSchemes { U Euler; T analytical; } } constantProperties { T0 320; // place holders for rho0 and Cp0 - reset from liquid props using T0 rho0 1000; Cp0 4187; youngsModulus 1e9; poissonsRatio 0.35; epsilon0 1; f0 0.5; Pr 0.7; Tvap 273; Tbp 373; constantVolume false; } subModels { particleForces { sphereDrag; } injectionModels { model1 { type coneNozzleInjection; SOI 349; massTotal 1.4e-06; parcelBasisType mass; injectionMethod disc; flowType pressureDrivenVelocity; Pinj 300e5; outerDiameter 1.3e-4; innerDiameter 0; duration 4; position (0.001200 0.000000 -0.00222); direction (1.0 0.0 -0.325); parcelsPerSecond 20000000; flowRateProfile table ( (0 0) (0.5 0.5) (1.0 1) (3 1) (3.5 0.5) (4 0) ); Cd constant 0.9; thetaInner constant 0.0; thetaOuter constant 20.0; sizeDistribution { type RosinRammler; RosinRammlerDistribution { minValue 1e-06; maxValue 0.00015; d 0.00015; n 3; } } } } dispersionModel none; patchInteractionModel standardWallInteraction; heatTransferModel RanzMarshall; compositionModel singlePhaseMixture; phaseChangeModel liquidEvaporation; surfaceFilmModel none; atomizationModel none; breakupModel ReitzDiwakar; // ReitzKHRT; stochasticCollisionModel none; radiation off; standardWallInteractionCoeffs { type rebound; } RanzMarshallCoeffs { BirdCorrection true; } singlePhaseMixtureCoeffs { phases ( liquid { C7H16 1; } ); } liquidEvaporationCoeffs { enthalpyTransfer enthalpyDifference; activeLiquids ( C7H16 ); } ReitzDiwakarCoeffs { solveOscillationEq yes; Cbag 6; Cb 0.785; Cstrip 0.5; Cs 10; } /* ReitzKHRTCoeffs { solveOscillationEq yes; B0 0.61; B1 40; Ctau 1; CRT 0.1; msLimit 0.2; WeberLimit 6; } */ TABCoeffs { y0 0; yDot0 0; Cmu 10; Comega 8; WeCrit 12; } } cloudFunctions {} // ************************************************************************* // |
|
Just tried it with sprayFoam and can confirm it crashes there, so it isn't just the engine version. Also tried different flow rate models and still crashed. |
|
So far I cannot reproduce your error using a similar setup for the sprayFoam aachenBomb case - can you provide a small test case? |
|
Weird, after a complete rebuild from scratch it is working, albeit now hanging after some parcel injection. I've seen some messages on the forums addressing this, so I'll keep working on it. |
|
I've uploaded a simple case that seems to indicate that there is an issue with the timing of injection. Its a simple cylinder mesh, using the injection profile from the aachenBomb case (with the engine RPM and time adjusted to give the same injection duration in real time. The log file shows that injection doesn't begin at the stated SOI, and there are problems integrating the profile. I've seen that other cases with similar timing work if we add 360 degrees (so the negative may have something to do with it). I remember that there was a bug in 2.1.x with spray models and engine time. Is this a possible resurrection? |
2013-05-09 17:27
|
|
2013-05-09 17:28
|
|
2013-05-09 17:28
|
|
2013-05-10 23:22
|
|
|
Ok, so I updated the case because there was a problem with the engine speed and spray location (its been a long week, apologies for the rapid changes), there are still issues with spray injection. |
|
The problem relates to the handling of your table - the duration is specified as 12.5 CA, but during the calculation, it is queried outside of this range by 1 time step. At the moment, bounds handling is not included in the table functionality = error We will look to include the bounds handling in the future (quicker with sponsorship), but as an interim work-around, extend your table to fully include the end of injection, e.g. by adding: ... (0.0012501e4 0) (1000 0) |
|
Thanks Andy. Your suggestion fixed the issues with the tables, but I still get hanging when injection starts. I've asked for some help on the forums, and it appears this might be a machine specific problem: http://www.cfd-online.com/Forums/openfoam-solving/117821-sprayenginefoam-problems-2-2-x.html Have there been any reports of problems with lagrangian sprays under OpenSUSE? |
|
> Have there been any reports of problems with lagrangian sprays under OpenSUSE? not that we're aware of have you tried attaching gdb to the process ID (XXX) and seeing where the code appears to be hanging? i.e. $ gdb -pid XXX $ where |
|
Here is the gdb output. I think there is an issue with the particle tracking: (gdb) where #0 0x080c1614 in __x86.get_pc_thunk.bx () #1 0x080d0ea6 in Foam::max<Foam::Vector<double>, double, 3> (vs1=..., vs2=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/VectorSpaceI.H:445 #2 0xb34c12a1 in Foam::treeDataCell::calcCellBb (this=0xb28f138, cellI=10951) at algorithms/indexedOctree/treeDataCell.C:63 #3 0xb34c1712 in Foam::treeDataCell::overlaps (this=0xb28f138, index=10951, cubeBb=...) at algorithms/indexedOctree/treeDataCell.C:163 #4 0xb625cfce in Foam::indexedOctree<Foam::treeDataCell>::divide (this=0xb28f138, indices=..., bb=..., result=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:148 #5 0xb625b193 in Foam::indexedOctree<Foam::treeDataCell>::divide (this=0xb28f138, bb=..., contents=..., contentI=154) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:193 #6 0xb625b55a in Foam::indexedOctree<Foam::treeDataCell>::splitNodes (this=0xb28f138, minSize=10, nodes=..., contents=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:274 #7 0xb6259c6f in Foam::indexedOctree<Foam::treeDataCell>::indexedOctree (this=0xb28f138, shapes=..., bb=..., maxLevels=8, maxLeafRatio=10, maxDuplicity=5) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/OpenFOAM/lnInclude/indexedOctree.C:2534 #8 0xb33c8ee0 in Foam::polyMesh::cellTree (this=0x9260d58) at meshes/polyMesh/polyMesh.C:913 #9 0xb33ca3d5 in Foam::polyMesh::findCellFacePt (this=0x9260d58, pt=..., cellI=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1) at meshes/polyMesh/polyMesh.C:1238 #10 0xb503714d in Foam::InjectionModel<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::findCellAtPosition (this=0xa1d95b0, cellI=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1, position=..., errorOnNotFound=false) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModel.C:115 #11 0xb505a561 in Foam::ConeNozzleInjection<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::setPositionAndCell (this=0xa1d95b0, position=..., cellOwner=@0xbf8077f4: -1, tetFaceI=@0xbf8077f0: -1, tetPtI=@0xbf8077ec: -1) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/ConeNozzleInjection.C:351 #12 0x08127adb in Foam::InjectionModel<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::inject<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xa1d95b0, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModel.C:537 #13 0x08113f45 in Foam::InjectionModelList<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > >::inject<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf808b6c, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/InjectionModelList.C:187 #14 0x0810053b in Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > >::evolveCloud<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf8087bc, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:188 #15 0x080e8c5e in Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > >::solve<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > >::TrackingData<Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > > > > (this=0xbf8087bc, td=...) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/intermediate/lnInclude/KinematicCloud.C:100 #16 0x080d4c19 in Foam::SprayCloud<Foam::ReactingCloud<Foam::ThermoCloud<Foam::KinematicCloud<Foam::Cloud<Foam::SprayParcel<Foam::ReactingParcel<Foam::ThermoParcel<Foam::KinematicParcel<Foam::particle> > > > > > > > >::evolve (this=0xbf8087bc) at /home/gandalf/OpenFOAM/OpenFOAM-2.2.x/src/lagrangian/spray/lnInclude/SprayCloud.C:235 #17 0x080c33d9 in main (argc=1, argv=0xbf809e94) at sprayEngineFoam.C:81 |
|
Just a quick update. The problem continues, with the only relief coming from reducing the timestep dramatically. The conditions at injection are similar to the aachenBomb case, and there have been reports that the injection works fine on other machines. Still trying to figure out what may be the problem. |
|
I have just installed both OpenSUSE 12.2 and Ubunutu 12.04 LTS on the same machine and can confirm the injection does not hang on Ubuntu but does on OpenSUSE. There is some underlying issue with the base libraries. I will see if this has been resolved in the newest OpenSUSE in the coming weeks. |
|
I don't think this is directly related to OpenSUSE vs. Ubuntu. There have been bugs in the Lagrangian spray library and your initial error message was definitely related to them (the TMax error). These bugs were resolved today (git commit b592ac38bfcd73383ae4eac77c78c64cee93af34), hence you need a recent 2.2.x git-checkout. I would be happy if you could test the new code. A note on OpenSUSE: We are using OpenSUSE for years (currently 12.2) and haven't had any distribution specific problem. |
|
I know, this is very odd. I installed both OS's on the same machine (clean install) and a fresh install of OpenFOAM 2.2.x (through the repository). Even before the recent commits, running the case in the thread above would hang in OpenSUSE and be fine in Ubuntu (including the custom engine solver). After pulling the newest commit and rebuilding everything, OpenSUSE still hangs. It might be a weird confluence of architechture, libraries or something. I think it will remain one of those unsolved mysteries. |
|
Well after all there are differences between distribution, I just wouldn't have expected that OF will run into problems because of that. This is indeed really odd. Maybe one more question: How do you install "OF through the repository" on OpenSUSE? Do you mean a git checkout and compiling it on your machine? |
|
Yes, I am installing the git repository and compiling, as I have a few custom solvers and boundary conditions I need for my simulations. |
|
@mturcios: Can you share the information about which versions of the GNU compiler/linker applications you're using for building OpenFOAM 2.2.x? Namely, the versions given by the following commands: gcc --version g++ --version ld --version because it's possible that you might be using conflicting versions on openSUSE or that you might be using the "gold" version of "ld"... although AFAIK, it should not have worked with "gold"... |
|
Thanks Bruno. Here are the results of the commands you specified: gcc --version: gcc (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773] g++ --version: g++ (SUSE Linux) 4.7.1 20120723 [gcc-4_7-branch revision 189773] ld --version: GNU ld (GNU Binutils; openSUSE 12.2) 2.22 |
|
An additional note, lagrangian injection hangs for sprayFoam and sprayEngineFoam on OpenSUSE 13.2 as well. This is after a clean install of the OS along with rebuilding OpenFOAM 2.2.x from repository and using the same case files that worked perfectly in Ubunutu 12.04 LTS. Very bizarre errors here. I think we may be switching to Ubuntu LTS for this reason as well as the long term stability. |
|
@Marco: I'm using the case attached named "plainCylinder.fixed.tar.gz" on the latest OpenFOAM 2.2.x, built on Ubuntu 12.04 x86_64, with Gcc 4.6.3. To run it, I used the commands: blockMesh foamJob sprayEngineFoam and am monitoring the file "log" to check if everything is running or not. I went back to read the whole history of this bug report and I can't figure out what I should be looking for exactly. When/where exactly does the solver hang in openSUSE? |
|
At around -14.35 CA, the solver gets to the "Solving cloud sprayCloud" line and mentions the parcels (usually less than 10), after which the solver hangs. No crash or error message, it just stays at that line. |
|
|
|
Attached is the case "plainCylinder.fixed2.tar.gz", which is based on "plainCylinder.fixed.tar.gz", with the following adjustments: - the field "alphat" should use "compressible::alphatWallFunction", because it was enforced as such in one of the somewhat recent 2.2.x commits; - as Andy indicated a few comments above, I added these two lines: (0.0012501e4 0) (1000 0) to "constant/sprayCloudProperties", in the table "subModels.injectionModels.model1.flowRateProfile". As I wrote above, I used the following two commands to run the case: blockMesh foamJob sprayEngineFoam I've tested in a virtual machine with openSUSE 12.3 x86_64, with the latest OpenFOAM 2.2.x (commit 0afc56c40d89e253fa2f5d7c5267c73aac548b69), using 2 different builds: - One where the default compiler choice is left as-is, namely: WM_COMPILER=Gcc - Another where the compiler chosen is more related to openSUSE's version: WM_COMPILER=Gcc47 More specifically, I used the following aliases for sourcing the desired environments: alias of22x47='source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc WM_NCOMPPROCS=4 WM_MPLIB=SYSTEMOPENMPI WM_COMPILER=Gcc47' alias of22x='source $HOME/OpenFOAM/OpenFOAM-2.2.x/etc/bashrc WM_NCOMPPROCS=4 WM_MPLIB=SYSTEMOPENMPI' My bet was on the issue being that the default compiler options were giving the problems, but I was not able to reproduce the same problem. In addition, both runs did not go through the "-14.35 CA" position, they simply did "-15 CA" and "-14 CA", and in neither one of these two angles were introduced new parcels. So my suggestions for now are as follows: 1- Test with this case I attached, to so that you can confirm if the same problem still occurs on your machine with openSUSE. 2- If it still happens, try using the "Gcc47" compiler option, as indicated above, or simply hack directly the "etc/bashrc" file and then start a new terminal and build OpenFOAM again. Because from everything else, the only remaining ideas that come to mind are: a) The solver you've created might be entangled with OpenFOAM's own core code, which leads to this problem. b) There could be a hardware-kernel problem, namely something in the kernel on openSUSE is not controlling properly your machine, while Ubuntu has everything under control. |
|
Re a) : from the traceback of your injection it seems to hang in the octree construction routines (using in finding cells). There are always potential numerical precision issues with any decision made based on floating point numbers so it might be that you've hit a corner case. - check that your injection location is well inside a cell and also not exactly at the middle of the domain in any component. - perturb your injection location and/or mesh slightly and see if this helps - is your geometry 2D? If so can you make it 'thicker' to be more cube like. |
|
On the compiler issue: OpenSUSE uses gcc4.7 as default compiler for 12.2 and 12.3. I wouldn't even know where to get another version from, except of the ancient gcc3.3 packages and compiling gcc from source. |
|
@dkxls: gcc 4.7 should work well with OpenFOAM. What I was talking about is the compiler options. To see what I mean, run these commands: foam diff -Nur wmake/rules/linux64Gcc wmake/rules/linux64Gcc47 It will show you the few differences there are in the compilation options that are used for building OpenFOAM, depending on the WM_COMPILER environment variable+options that I mentioned. |
|
@wyldkat: I'm sorry, I forgot to mention that I changed the SOI to be -14.5 to see the results sooner. The other changes you made (alphat->compressible::alphat and the injection profile) I had also implemented. Still same result. As far as hardware, it may be possible since both machines this has happened on are Intel (one is a Xeon, the other is a P4 we had lying around). I don't think the custom solver is entangling with the core one, as I am running sprayEngineFoam as a test before I even compile my solver. Thanks everyone for your help; it seems like this is a case where we may never get the straight answer, and the effort involved to track it down is not worth it. I'll revisit this every now and again, but at this time switching to Ubuntu seems the best fix available. |
Date Modified | Username | Field | Change |
---|---|---|---|
2013-05-06 19:19 |
|
New Issue | |
2013-05-06 19:19 |
|
File Added: sprayCloudProperties | |
2013-05-07 22:39 |
|
Note Added: 0002178 | |
2013-05-08 08:56 |
|
Note Added: 0002179 | |
2013-05-08 08:56 |
|
Priority | immediate => normal |
2013-05-08 18:17 |
|
Note Added: 0002182 | |
2013-05-09 17:27 |
|
Note Added: 0002184 | |
2013-05-09 17:27 |
|
File Added: log.dat | |
2013-05-09 17:28 |
|
File Added: logSummary.-180.dat | |
2013-05-09 17:28 |
|
File Added: plainCylinder.tar.gz | |
2013-05-10 23:22 |
|
File Added: plainCylinder.fixed.tar.gz | |
2013-05-10 23:26 |
|
Note Added: 0002187 | |
2013-05-13 11:34 |
|
Note Added: 0002190 | |
2013-05-16 21:24 |
|
Note Added: 0002215 | |
2013-05-20 09:41 |
|
Note Added: 0002219 | |
2013-05-21 18:46 |
|
Note Added: 0002229 | |
2013-06-25 17:32 |
|
Note Added: 0002293 | |
2013-08-09 17:43 |
|
Note Added: 0002387 | |
2013-08-09 22:24 | dkxls | Note Added: 0002388 | |
2013-08-09 22:57 |
|
Note Added: 0002389 | |
2013-08-10 12:06 | dkxls | Note Added: 0002391 | |
2013-08-12 17:02 |
|
Note Added: 0002392 | |
2013-08-13 20:17 | wyldckat | Note Added: 0002400 | |
2013-08-13 20:22 |
|
Note Added: 0002401 | |
2013-08-14 19:55 |
|
Note Added: 0002412 | |
2013-08-14 21:55 | wyldckat | Note Added: 0002414 | |
2013-08-14 22:58 |
|
Note Added: 0002415 | |
2013-08-15 01:13 | wyldckat | File Added: plainCylinder.fixed2.tar.gz | |
2013-08-15 01:33 | wyldckat | Note Added: 0002416 | |
2013-08-15 09:02 |
|
Note Added: 0002418 | |
2013-08-15 09:37 | dkxls | Note Added: 0002419 | |
2013-08-15 11:19 | wyldckat | Note Edited: 0002416 | |
2013-08-15 11:23 | wyldckat | Note Added: 0002420 | |
2013-08-15 16:52 |
|
Note Added: 0002421 | |
2013-08-15 16:54 |
|
Note Edited: 0002421 | |
2013-08-15 17:24 |
|
Note Edited: 0002421 | |
2015-02-05 09:20 | henry | Status | new => closed |
2015-02-05 09:20 | henry | Assigned To | => henry |
2015-02-05 09:20 | henry | Resolution | open => no change required |