[kompe]

Hi!
I am trying to follow this simple procedure to add temperature solving to icoFoam, as outlined here; https://openfoamwiki.net/index.php/H...ure_to_icoFoam


When I try to do wmake (before any changes to the code, other than renaming files), I get the following error:

/home/user/OpenFOAM/OpenFoam-v2106/src/OpenFOAM/lnInclude/face.H:52:11: fatal error: surfacePatchList.H: No such file or directory
   52 |  #include "surfacePatchList.H"
      |           ^~~~~~~~~~~~~~~~~~~~
 compilation terminated.

Do you have any idea what is going on here?

[kompe]

I recompiled OpenFoam with all dependencies, and now it seems to work. (Still don't know why, though.)

[dlahaye]

At times it is valuable to distinguish between OpenFoam (specific) and C++ (more general).

In compiling C++ (and other languages) code one distinguishes between compiling (typically using compiler with -c option) to obtain object code (*.o file) and linking to obtain executable.

The error you point out refers to the compile stage. The compiler does not find the header (*.H) file because you haver not told the compiler where (which directory) the header file is located using the -I option.

You can look into C++ tutorials to convince yourself.

[olesen]

Originally Posted by kompe

Hi!
I am trying to follow this simple procedure to add temperature solving to icoFoam, as outlined here; https://openfoamwiki.net/index.php/H...ure_to_icoFoam


When I try to do wmake (before any changes to the code, other than renaming files), I get the following error:

/home/user/OpenFOAM/OpenFoam-v2106/src/OpenFOAM/lnInclude/face.H:52:11: fatal error: surfacePatchList.H: No such file or directory
   52 |  #include "surfacePatchList.H"
      |           ^~~~~~~~~~~~~~~~~~~~
 compilation terminated.

Do you have any idea what is going on here?

The files cannot be found, which usually happens if your changes have somehow bypassed the regular wmake mechanism. The wmakeLnInclude script is one of the helpers you are looking for.


The longer explanation: the OpenFOAM code hierarchy for each src/... directory is flattened out into a single "lnInclude" directory of symlinked files. This makes it much easier to handle since the code can then simply include the header without specifying the subdirectory path, or without adding loads of different include directories into the compilation line. When compiling a "libso" target, the wmake scripts will generate and populate the lnInclude directory with symlinks. If header files are added or moved later, it can be that they are missing from the "lnInclude" and you will have to address that yourself.

Here is what I normally do.
- Determine where the file is really located. It certainly helps if you have git installed, but the 'find' command will also work (but slower). Here is the git approach (I do it frequently enough that I actually have a git-find script with a few more options).

$  cd $WM_PROJECT_DIR
$  git ls-tree -r HEAD | grep surfacePatchList


100644 blob d25f2ede35a773fa063e0cd6f936bc98395331f4    src/surfMesh/triSurface/patches/surfacePatchList.H

As this shows, the file in question is located somewhere below the src/surfMesh hierarchy.
- use wmakeLnInclude to (re)create the corresponding symlinks.

$  cd src/surfMesh     # This is what we found in the previous step

$  wmakeLnInclude -u -pwd   # Update

Note that for the wmakeLnInclude we use the convenient '-pwd' option. This makes it easier to use (avoids errors) by locating the correct path containing the Make/ directory. That means that the following command would work equally well:

$  cd src/surfMesh/triSurface/patches     # location of the header file

$  wmakeLnInclude -u -pwd   # Update

After this the file should be properly found in the lnInclude directory and you can get on with compilation.


Side-note: sometimes if you juggle the contents of the headers and remove some included files the dependency check can get a bit wrecked (ie, it tries to check if a now nonexistent file is up-to-date). For these cases you can use the `wrmdep` to remove the old, dirty dependency file. In some cases, however, it can be useful to replace the removed file with a dummy stub such as provided in `etc/codeTemplates/removed-file`:

#warning File removed - left for old dependency check only

This ensures that the next compilation can still access the file for updating the dependency check. After it has been updated once, the file is never actually needed again.


I hope that this answers more questions than it raises.

[kompe]

Thanks a lot for your answer!
This does explain a lot. And it shows that I do not at all know as much as I would like to about the architecture of complex software and how it is managed and compiled. I usually type 'wmake' or some other code snippet I copied from somewhere and cross my fingers. I feel like a blind man when I stumble upon these sorts of errors - but thanks for shedding a little light.