Umm... You would need to download and install OpenFOAM-1.6-ext first.
Clone the repository: git clone ssh://username@openfoam-extend.git.sourceforge.net/gitroot/openfoam-extend/OpenFOAM-1.6-ext Installation instructions are here: http://openfoam-extend.git.sourcefor...a69f5e;hb=HEAD |
Thanks for the link.
I was able to download the package, but there isn't much in the way of executable binaries that seem to come with it. Trying the AllMake scripts from the ThirdParty directory, but it's slow going. The default value for WM_THIRD_PARTY_DIR points to the wrong directory, and the values in the README files also seem to be inconsistent with the install. After downloading & installing some additional packages (via YaST), I can get AllMake.stage0 - 2 to run without incident. AllMake.Stage3 may or may not be failing; I get this: Code:
RPM build errors: I don't know if this is related to earlier troubles with OpenFoam - I've tried recompiling the code twice earlier, but it destroys its own binaries and spits out lots of errors. It's possible that my messing with /opt/openfoam171/etc/bashrc to re-point WM_THIRD_PARTY_DIR *might* have fixed that too... I'll poke around and see what else I can find. Any advice you can give me would be great. Thank you |
It looks like you're messing up different Foam installations. It might help to unset the WM_THIRD_PARTY_DIR in your .bashrc, and do a foamInstallationTest to ensure that everything's okay.
|
Oh... I think I get it. Are you sourcing your 1.6-ext bashrc? Make sure you have a line like this in ~/.bashrc
# Source the OpenFOAM-1.6-ext installation . ~/OpenFOAM/OpenFOAM-1.6-ext/etc/bashrc ... and do a foamInstallationTest to make sure it's okay. You appear to be using a central OpenFOAM-1.7.1 installation through YaST, where the ThirdParty directory is located differently. |
If I put "unset WM_THIRD_PARTY_DIR" at the end of my ~/.bashrc and source the file, foamInstallationTest gives me this:
Code:
Executing /opt/openfoam171/bin/foamInstallationTest: Code:
Executing /opt/openfoam171/bin/foamInstallationTest: What do you mean by Quote:
Is OpenFOAM-1.6-ext incompatible with OpenFoam 1.7.1? Should I go looking for OpenFoam 1.6? Thanks |
OF-1.6-ext and OF-1.7.1 can coexist without problems. All you need to do is make sure that the relevant bashrc is being sourced correctly. Here's a sample of mine:
Code:
# Source the OpenFOAM-1.5-dev installation |
Okay, that makes sense now - I'd been treating OpenFOAM-1.6-ext as just a bunch of add-ons, but it looks like it makes more sense to treat it as a standalone package....
so it's now in /opt/openfoam16x/OpenFOAM-1.6-ext/ I was trying to mimic the directory structure for openfoam171, but it looks like that got messed up somehow. I've tweaked foamInstall in the etc/bashrc, though, so hopefully that's fine. ./Allwmake from the OpenFOAM-1.6-ext directory gives a number of "No such file or directory" errors related to specific header files: mpi.h, and decompositionMethod.H, which are apparently needed by OPwrite.C, IPread.C, scotchDecomp.H, metisDecomp.H, and parMetisDecomp.H I've three different mpi.h on my system, under: paraviewopenfoam381 linux-2.6.34.8.0.2 linux-2.6.34.8-0.2-obj There are five different OPwrite.C and seven different IPread.C; is there a way to make the error more specific? Is there a way to tell which environment variable needs to be twiddled to make it go? Thank you once again. |
So tried that "foamInstallationTest" you mentioned before (should've done it before I posted, but the "Submit Reply" button's tempting... and I want to log my error path too...):
Code:
Checking basic setup... *sigh* |
Almost there, but not quite. Again, you shouldn't have to edit files anywhere to get this to work - a single line in your .bashrc should suffice.
I see you've opted for a central install - this is fine (although I personally wouldn't use this approach), but you probably want to be root before building things, if you do it this way. Make sure that the ThirdParty directory has been built before an Allwmake in the OpenFOAM-1.6-ext directory (easy enough to do - an Allmake in the $WM_THIRD_PARTY_DIR will get you going). The ThirdParty directory contains sources to MPI, metis, scotch, etc., so your problems should go away once that is done. This thread appears to have become hijacked for installation, when it should've been addressing 'sonicDyMFoam', and that's rather unfortunate. Remember, the forum search function is your friend. |
Sorry about the threadjack. It wasn't intentional. I've continued describing my attempts to install OpenFOAM-1.6-ext here.
|
I tried adapting the movingConeTopo case from OpenFoam-1.6-ext to use the sonicDyMFoam solver instead of the icoDyMFoam, but ran into trouble:
1) sonicDyMFoam doesn't exist under 1.6-ext (I've a compressible fluid traveling at transonic velocities, so icoDyMFoam used in the movingConeTopo case won't work.) 2) 1.7.1 sonicDyMFoam and 1.6-ext icoDyMFoam apparently set up the dynamicMeshDict differently. (e.g. 1.6-ext icoDyMFoam doesn't have a pointMotionUx field or the "solver" keyword, both of which are apparently required for 1.7.1 sonicDyMFoam) I've tried a couple different ways to set it up, but I either get crashiness or a mesh which apparently splits into two overlapping, inconsistent grids after the first time step. (After splitting the mesh, sonicDyMFoam continues to run for a while, but eventually things get so strained that it crashes.) The meat of my dynamicMeshDict is: Code:
FoamFile I tried looking at some of the source code in $FOAM_SRC/dynamicFvMesh/solidBodyMotionFvMesh/solidBodyMotionFunctions but 1) I'm not sure if that's applicable to me, and 2) although I can see a few things that look familiar, I don't see the requirements for pointMotionUx in this or any of the other code under $FOAM_SRC/dynamcFvMesh Can I get a pointer to something relevant? Maybe a help file? or a tutorial? You know, "Baby's first sonicDyMFoam case"? Thanks. |
Hmm... It does look like sonicDyMFoam doesn't exist on 1.6-ext. But the solver should be compatible - copy it over to your 1.6-ext installation from 1.7.x, compile it and see.
It would help to see some pictures of what your problem is, and a log file of the run, if that helps. |
2 Attachment(s)
Okay,
so the problems I reported before got resolved by rebooting my machine. I'd tried unsetting $FOAM_INST_DIR and re-sourcing my (revised for 1.6-ext) .bashrc, but that seems to be incomplete: there are some state variables somewhere which were still pointing to 1.6-ext, while others pointed to 1.7.1 Once I rebooted, I was able to run sonicDyMFoam under OpenFOAM 1.7.1, but instead of the libtopoChangerFvMesh effect of moving grid cells from one side of the poppet to the other as the poppet moved, I instead got the dynamicMotionSolverFvMesh effect of constant # of grid cells stretching as the poppet moves. (To recap, this causes trouble because the cells on one side get squeezed down to a huge aspect ratio while those on the other side stretch to horrid resolution.) I'm attaching a couple pix of the mesh from the 1.7.1 run to show how it changed. (Yes, my initial mesh is lopsided, but I figured I'd deal with that after I sorted out the not-running issues.) So after that, I tried your suggestion of copying everything (my "valve" case and the sonicDyMFoam source) over to 1.6-ext, this time making sure to edit the .bashrc and do a full reboot before fiddling with anything important. I tried running Allwmake from the OpenFoam-1.6-ext directory, but ran into some "motionSolver.H" not found errors. So I compared the directory structures on each side, and found that motionSolver.H shows up in four places under OpenFOAM 1.7.1: Code:
src/dynamicMesh/motionSolver Then I switched back to the "run/valve/constant" directory and tried editting dynamicMeshDict to be close to the original plan for the "movingConeTopo" case... Apparently 1.6-ext dislikes the "inletOutlet" boundary conditions I was using under 1.7.1, so I closed off the boundaries, basically making the inletOutlet faces look like hard walls. (Not real happy about that, but at least it'll let me address the meshing issues until I figure out how 1.6-ext handles open boundaries.) Along the way, I found that under 1.6-ext, I need to run "cp -r 0.org 0" between the ./Allclean and ./Allrun scripts. After that, I found that sonicDyMFoam complains that I haven't put the "solver" keyword in constant/dynamicMeshDict, despite the fact that it wasn't in the original icoDyMFoam example I've been using as a model: Code:
FoamFile Code:
--> FOAM FATAL IO ERROR: Code:
FoamFile Code:
Selecting motion solver: velocityComponentLaplacian |
The dynamicMesh directory structure is different from OF-1.7.x, so it's not surprising that sonicDyMFoam doesn't compile.
Quote:
Also, looking at the sonicDyMFoam sources, it's geared for mesh-motion alone, and not topo-changes. You'll have to re-write a bit if you're planning on introducing layering (i.e., using the topoChangerFvMesh stuff). I would also look into the tetDecompositionMotionSolvers / mesquiteMotionSolver for mesh-motion, which may alleviate some of your issues. |
just to make sure I understand... you're recommending that I edit sonicDyMFoam.C so that it runs with topoChangerFvMesh.C instead of velocityComponentLaplacianFvMotionSolver.C, which I think I've used above (or else, tetDecompositionMotionSolver.C or mesquiteMotionSolver.C might be more useful)? Do you have anything which compares the three dynamicMesh solvers? Without knowing what features / types of mesh motion are available in each, it's a bit hard to choose between them.
I took a glance at each of the source files mentioned above, and while I got some quick impressions of what was going on, what I'm supposed to do didn't leap out at me. (That may be because it's been more than a decade since I did serious C coding and that was mostly C, with only a bit of C++, and on a much smaller scale than OpenFOAM.) If I understand you right, I should only need to edit sonicDyMFoam.C, and only the parts that deal with meshing? Will I need to copy over the fields to the new grid manually, or do the dynamicMesh solvers handle that for me? What about the changes to the vector fields and vector operators? I'm hoping that the dynamicMesh solvers will handle all that if I just call the appropriate functions.... Do you have links for documentation on them? Or maybe sample code with & without changes similar to those I'll need to make? Forgive me if I'm skittish or seem a bit dull. I haven't edited OpenFOAM source before, and there's clearly a lot of data-hiding and operator-overloading going on... and the in-file documentation is aimed at folks who're familiar with the code. Thanks again for your help. |
Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
|
Was missing several libraries during compilation... I'm not sure if I'm doing right by dropping some of them; I'm trying to redirect them in those cases where I can find appropriate things - but several of the .H files appear to be very application-specific.
I'm also having trouble getting this to compile. The current resistant error is Code:
sonicDyMFoam.C:(.text+0x1ddb): undefined reference to `Foam::dynamicFvMesh::New(Foam::IOobject const&)' I'd hoped the 0x1ddb was a byte offset in the source file, but the file's not that long.... I mean, I'm pretty sure the error has to do with a call to the New() method of the dynamicFvMesh class, which subclasses Foam, but... I don't know where the code calls that or how to address it. (Include additional libraries? drop a couple lines? write something from scratch?) Here's the current state of my code: Code:
#include "fvCFD.H" |
Linker issue. You're probably missing an -ldynamicFvMesh in your Make/options file.
|
Okay, the -ldynamicFvMesh got sonicDyMFoam to compile, but trouble results when it runs because the (custom) dynamicFvMesh, "puffValveTopoFvMesh" isn't being recognized. I described the results in some detail here. I think the main question I have now is "How do I get the OpenFOAM suite to recognize I've added a new dynamicFvMesh. (I suppose I can replace / edit one of the existing utilities, but that seems like an inappropriate solution.)
Thank you |
That's now fixed, but I'm running into a dimensions error when I try to run my modded sonicDyMFoam:
Code:
Different dimensions for -= (Note to fellow n00Bs: Many of OpenFOAM's *.H files contain code, not just prototypes, macros, and compiler directives. That's a big change from the "C 101" courses I took nearly twenty years ago...) Anyhow, I put the includes back, which required me to track down definitions that happen in different files for different solvers. The end result is mostly the original sonicDyMFoam.C, but mixes in bits from compressibleInterDyMFoam.C and icoDyMFoam.C. Here's the code: Code:
/*---------------------------------------------------------------------------*\ readControls.H (copied from icoDyMFoam.H) correctPhi.H (copied from compressibleInterDyMFoam.H) and createFields.H: Code:
Info<< "Reading thermophysical properties\n" << endl; Thanks once again for the help |
All times are GMT -4. The time now is 20:17. |