Many very thanks for your reply and assistance!

Best!
K

First of all, thanks Bernhard for the patch.

Does the FOAM_SIGFPE environment setting work with this patch on OS X?

It doesn't for my installation. Having it set or unset makes no difference, the signal seems to be ignored. If mess up a run and get a NaN in a variable, the solver keeps right on ticking.

I don't see any changes made by the patch in the sigFpe source files, so I don't think it should work, but I thought I'd ask, in case I'm missing something.

Thanks.

JU

Doesn't work for me either. Didn't investigate the matter too closely. One reason could be that the sigFpe is never raised (this might be a matter of compiler-switches or it has got to be enabled by some system call). But I never investigated it too closely

Bernhard

Greetings to all!

I believe this is something that has also been fixed in Symscape's patches, as well as in FreeFOAM.

If I'm not mistaken, check the patches for the file "src/OpenFOAM/primitives/Scalar/doubleFloat.H", right after the "#include <cmath>":

• Symscape's modifications:
  Code:

  ---

  if defined(DARWIN)
#define j0f j0
#define j1f j1
#define jnf jn
#define y0f y0
#define y1f y1
#define ynf yn
#endif

  ---

• FreeFOAM's modifications:
  Code:

  ---

  #ifdef darwin
#ifndef DUMMY_SCALAR_FUNCTIONS
#define DUMMY_SCALAR_FUNCTIONS
inline float j0f(float x) { return float(j0(double(x)));}
inline float j1f(float x) { return float(j1(double(x)));}
inline float y0f(float x) { return float(y0(double(x)));}
inline float y1f(float x) { return float(y1(double(x)));}
inline float jnf(const int n, const float s) { return float(jn(n, double(s))); }
inline float ynf(const int n, const float s) { return float(yn(n, double(s))); }
#endif
#endif

  ---

Best regards,
Bruno

I don't think that that's it. My patches do something similar. Basically the "problem" that is fixed here is that Apple in its infintie wisdom thought that j0f et al are not necessary for single precision and these patches provide dummy-implementations to those functions (basically they call the double-precision implementation). But I don't see how this would affect the FPE

Bernhard

Thanks Bernhard.

Floating point exceptions seem to be handled in sigFpe.C, and there are some Linux calls in there (feenableexcept() for example) that aren't implemented in OS X. Don't know the corresponding functions in OSX, but I can keep looking.

Thanks for the pointer to FreeFoam, Bruno. It doesn't seem like they implemented this functionality, but I haven't been through it completely yet.

Regards,

Joe

Hi Bernhard and Joe,

I'm sorry, but I assumed this issue was resolved already, due to this post on Symscape's blog. My deduction was that since the patches already had this fixed for MinGW, it would only be reasonable that a POSIX respecting Darwin system would have this more than solved... but I guessed it wrong :(
Also a bad assumption was that FreeFOAM (which does have support for Mac OS X for a while now) would already have this fixed as well.

By the way Joe, you might want to see the pu branch of FreeFOAM, which is the bleeding edge of FreeFOAM.

Best regards and good luck!
Bruno

PS: I've tried having a look at GNU-Darwin, OpenDarwin and PureDarwin, but they currently seem to be dead ends :( Too bad there still isn't a RHEL/CentOS like thing with Mac OS X... oh well.

Troubles with MPI
 

Hi foamers,
I successifully installed OF, but I'm getting troubles with MPI. I'm following the wiki: http://openfoamwiki.net/index.php/Ho...enFOAM_v17_Mac

Point 3 states that one should make some links in /Volumes/OpenFOAM/1.7.0/ThirdParty-1.7.0/platforms/darwinIntel64/openmpi-1.4.1/lib
However, this directory does not exist in my case.

I have another version of mpi on my computer (MacBook Pro with Snow leopard), which runs well if the OpenFOAM.dmg is not linked. I try then to link this direcly, making a ln -s to the location where the libmpi.dylib is.

In any case, as the OpenFOAM.dmg disk is linked I get:

> mpirun
--------------------------------------------------------------------------
Sorry! You were supposed to get help about:
orterun:usage
from the file:
help-orterun.txt
But I couldn't find any file matching that name. Sorry!
--------------------------------------------------------------------------

Any guess..?

Thanks,
Daniele

Solved!
 

Hi Foamers,
I found the solution, and I thought it would be nice to post it, perhaps it will be useful.
During the compilation of MPI, a series of files are created and sequentially used for the continuation of the compilation. For some reason (if anyone has guesses...let me know..!) these files are created with the .loT extension, whereas the compiler searches for .lo files.
The solution I found is then recompile by hand MPI:
The compiler will crash as a .lo file is not found. The good news is that the compiler reports the missing file name. The extension can be then changed using (from the directory where .loT file is) a command such:

This takes quite a while, but at the end it successfully compiles the libraries in the specified path [/OpenFOAM/ThirdParty-1.7.x/platforms/darwinintel64/openmpi-1.4.1].

Furtermore, for some reasons the wrappers are not well named (mpi at the place of openmpi). So it is necessary to create links in the dir:
as ( should this be done for all files..? ):

However, I'm sure that there's the way to modify a makeFile to solve the problem 'automatically'. I'd be really happy to get any advice about this

Regards,
Daniele

Prebuilt disk image of OpenFOAM 1.7.x for OS X 10.6.5
 

Hi Foamers,

Thanks to gschaider's ingenious patches I have a fully working (sans Tecplot360) installation of OF 1.7.x on Snow Leopard 10.6.5 (DPOpt on 64-bit).

By deleting the build files, wmake files, documentation, sources, tutorials and other miscellany, I could bring down the used space on the disk image to just about 280mb. It only has the binaries now.

Compressing this dmg made it 104MB. I hope it's okay to post a link to this, in case someone wants a prebuilt image of OF1.7.x for OS X. You can get it at http://macof17x.blogspot.com.

It has all the standard solvers and utilities except Tecplot360 conversion. You can decompose (including w/ metis) and run cases in parallel.

Thank you gschaider for a massive effort. Thanks to chrisb for a great and crisp explanation on his blog.

Hi!

Nice that somebody takes it upon him to support a binary release of 1.7 on the Mac.

Using the attached patch (inspired by the symscape-patches) I managed to compile the tecplot-converter. When running it fails with an unresolved reference in the tecio-library. I didn't have a deeper look as I don't use Tecplot anyway.

Bernhard
Attachment 5868

Problem (Probably Stupid) Using Precompiled Distribution
 

Hi everyone,

I'm brand new to OpenFOAM and relatively to heavy command line work in Unix systems. I've installed successfully using the tutorial on Sushant's website (thanks again!), but I'm having issues running the tutorials. So far I've tried running blockMesh and paraFoam. They seem to run correctly but both return an error along the lines of "file does not exist: './system/controlDict'". Should I have a system directory in my OpenFOAM installation, or do I need to change some environment variables somewhere?

Thanks,
Theron

No. The commands expect your current directory to be a valid OF-case (and a valid OF-case always has a file system/controlDict). I don't know the mentioned tutorial, but I guess you forgot a "cd" somewhere

Bernhard

Chris,

Can you tell me how to use this?

hdiutil attach "/path/to/your/disk_image.dmg" -mountpoint "$HOME/OpenFOAM" > /dev/null

I just used "Disk Utility" to create a case-sensitive disk named OpenFOAM. the path to it is /Volumes/OpenFOAM

I tried to create a file ~/.bashrc, and edit it as:


hdiutil attach "/Volumes/OpenFOAM/" -mountpoint "$HOME/OpenFOAM" > /dev/null

. $HOME/OpenFOAM/OpenFOAM-1.7.1/etc/bashrc


Then when I try to source it by command line ". ~/.bashrc", I get the following error messages:

hdiutil: attach failed - not recognized
-bash: /Users/zcheng/OpenFOAM/OpenFOAM-1.7.1/etc/bashrc: No such file or directory

So how Can I point the $HOME/OpenFOAM to /Volumes/OpenFOAM ?

I get confused at this step. Thank you for any help!

Thank you
 

Thank you for your prompt reply!

Right now, I'm trying to use Prebuilt OpenFOAM-1.7.x which is in your signature.

However, after I install it, I found that there is no tutorials folder, so where can we find these files? can I just copy the tutorials from the other places?

Thank you again !

Yep - sorry about that - there is no tutorials folder in the prebuilt image.

The source is also kept out - you won't find the src folder either. I figured if someone wants the source, they'd be the kind who would compile it (and thus not need a binary). In other words, those who need a binary don't usually need source, if they did, they would probably be able to compile it themselves. An exception is someone who wants the code just to study and understand it and not necessarily compile.

The tutorials folder was a gray area - probably a (silly) reason to decide on keeping it out was that it made the final disk image less than 100MB (99MB) but with the tutorials it was about 25% more.

I used to have a ~ 25MB zip file with the tutorials - just the tutorials - on the sourceforge page for this (hmm, I realize I have a sourceforge page on which I have uploaded just a binary and no source - violation of their TOS) but later removed that file because I felt it was redundant (OpenFOAM-1.7.1.gtgz provides the tutorials and it is around 50MB itself)

So coming back to the point ( :) ) the best place for now to get the tutorials would be OpenFOAM-1.7.1.gtgz from the OpenCFD website.

hi,leo
I use coalChemistryFoam of OF1.7.1 to deal with my case which is about coal injection combustion,I run the simplifiedSiwek case,it work well,but for my case,it "out of temperature range",can you help me to solve it?
best regards
ying

Is this a specific issue you face only on the MacOS build?

In general when I get out of temperature range errors I modify the solver to bound temperatures between the working range. This may happen in hypersonic flows or combustion simulations. For example, just after the energy equation is solved, do (use h or e as appropriate):

where hMin and hMax are dimensionedScalars created in createFields.h in the solver directory. You can create them by reading from the fvSolution dict. See the rhoPorousSimpleFoam or rhoSimpleFoam solver, I'm not sure which, it reads a pMin value from the fvSolution dict and places a lower-bound on the pressure accordingly.

Obviously, the bounds you set must be realistic and must allow for some leg space, and your converged solution field must not have this bounding. (To be sure, just print out a message to the screen when you bound; such messages are often spit out for k and epsilon for example).

AND/OR try lowering your relaxation factors way down. A combination of both usually works for me.

Again, do not trust bounding unless your temperature limits are realistically set, and your converged solution is well within bounds. Setting limits is not always easy; h=Cp*T and you are trying to limit T by limiting h, but Cp may or may not be constant depending on your modelling. It's worse when you're dealing with e.

(This may have been better off in another thread?)

Hope this helps,
Sushant

1.I'm work on ubuntu10.04.
2.how to do these?can you paste the changed file?
3.which relaxation factors do you mean?
Another question:can I just change the temperature bound?--I just think of it,but I don't know where to set the temperature bound