You're messing up compressible / incompressible versions - you're probably looking for:
fvc::makeRelative(phi,rho,U); which will additionally interpolate rho to faces and include that in relative fluxes, which should take care of the dimension problem. Take a look at ($FOAM_SRC)/finiteVolume/fvc/fvcMeshPhi.C for details on the implementation. Cheers |
getting there.... sorry this is taking so many rounds.
I replaced the several calls to fvc::makeRelative(phi,U); with fvc::makeRelative(phi,rho,U); Then did the same for fvc::makeAbsolute(phi,U); to fvc::makeAbsolute(phi,rho,U); figuring that the Absolute <=> Relative transformations should be symmetric. I did not change the calls to fvc::meshPhi() because those seemed to be declared & used appropriately. Upon getting the run-time error "keyword pFinal is undefined in dictionary", I copied the system/fvSolution::solvers::p entry over to pFinal. (I couldn't find explicit advice in a quick search, but figured that'd be okay even though it's probably not numerically optimal.) Running again gave a segmentation fault early in the second timestep. Tossing in various output checkpoints let me track the segmentation fault to where my sonicDyMFoam.C code calls bool meshChanged = mesh.update(); (near the beginning of the iteration). That call goes to my topoChanger library (custom, pffValveTopoFvMesh.C, posted earlier in this other thread)That function crashes on the line autoPtr<mapPolyMesh> topoChangeMap = topoChanger_.changeMesh(); I haven't tracked that down yet, but I'm guessing the SegFault means that something's subtly bad about either puffValveTopoFvMesh.C or my modified sonicDyMFoam. Let me know if you can give me ideas on what to tweak next. Thank you. |
Probably an out-of-bounds memory access.
Set the WM_COMPILE_OPTION environment variable to 'Debug', and re-compile your library - you can get a line number where your solver crashed. Also, set FOAM_ABORT to 1 to get a stack-trace. |
with both of those turned on, the tail of the log file is:
Code:
Creating field DpDt Code:
diagonal: Solving for rho, Initial residual = 0, Final residual = 0, No Iterations 0 |
hmmm...
I was worried the above didn't look sufficiently detailed / verbose, so I tried using touch and Allwmake to force a top-to-bottom recompile of OpenFOAM-1.6-ext. That was a bad idea - I got a large number of error messages on the recompile, and at least one quasi-unrelated application (sonicFoam, or more likely one of the libraries / utilities it calls) seems to have developed some novel behaviors. Rebooted to clear out the environmental vars and re-tried that recompile... no compile errors that way, but sonicFoam's still being silly. (The "p" output files repeat a section of output data & keywords, which confuses paraview... will post a description elsewhere and link to it if my poking about doesn't fix this soon.) Also, the datestamp on sonicFoam and most of the other applications' binaries is a month ago... |
Sorry to dig the old post.
I'm try to use sonicDyMFoam now, and faced with the same problems. Have you been solve this problems? Thanks! Janry |
Hi everyone,
I know this is very old thread, but I'm phasing same problem. There is no tutorial for sonicDyMFoam. Can someone help me please regarding issue. Quote:
|
All times are GMT -4. The time now is 02:32. |