[floquation]

Dear FOAMing Eclipsenturers,


Multiple people have experienced this problem (or here), in which you have a code which compiles and works flawlessly, but Eclipse is showing a dozen of "errors":

Symbol 'runTime' could not be resolved
Symbol 'mesh' could not be resolved
Invalid Arguments ' Candidates are ... '

Very annoying, especially since Eclipse's powerful features like "Open Declaration" and "autocompletion" will not work properly, if at all.
The source of this error is that Eclipse's indexer (=the program Eclipse uses to parse your files and find where methods/variables are declared etc.) does not understand the way in which OpenFOAM #include-s some files. The compiler (e.g. gcc) is independent of the indexer and does understand what OpenFOAM is doing. Hence your code compiles, but Eclipse shows you errors.

By chance or educating guessing, I stumbled upon a partial solution. So don't get your hopes up too much: it is not perfect.
However, it will fix all serious errors, making "Open Declaration" and "autocompletion" to work flawlessly inside the C-file (see the attached screenshot). For details of the advantages/disadvantages, please check out the tutorial.

As a continuation to this thread, I have written a new tutorial of how to use OpenFOAM within Eclipse CDT on the OpenFOAM wiki. This new tutorial focuses specifically on "fixing" the Eclipse indexer and is therefore an extension to this tutorial.


Link:
Enabling symbol recognition and autocompletion in Eclipse by fooling the indexer


Any suggestions / improvements / other thoughts are welcome.

Enjoy Eclipse!


-- Kevin

[giordy]

Hi Kevin.

I tried to follow your tutorial and most of my errors disappear. However i still have 4 error like this: Error: Invalid arguments ... Candidates are ...

I trying to compile icoFoam and the first error appear for grad(p) at this line

solve(UEqn==-fvc::grad(p));

I am using the following version of eclipse and openfoam 3.0.1:
Eclipse IDE for C/C++ Developers
Version: Indigo Service Release 1
Build id: 20110916-0149

I am including the files in the right order as you explained. Is there a way to figure out where the problem is?
thanks. regards,
Stefano

[floquation]

According to my FAQ, that error occurs when the variable name is known, but the variable type is not.

The variabletype of pressure is volScalarField.

If I follow volScalarField (Eclipse: F3), it is defined in volFieldsFwd.H.

If I open the include hierarchy of that file (Eclipse: Navigate -> Open Include Browser), we can see that it, at the root, is being included by fvCFD.H.

Question:
Did you include fvCFD.H as the very first include file?

(And I assume you included the OpenFOAM and finiteVolume etc. lnInclude directories, right? Otherwise the #include statements wouldn't be recognised.)

---

Also note that indexing will not work properly with the way in which OpenFOAM includes files. That is, it will work flawlessly in icoFoam.C, but it will not work properly in UEqn.H, which is included by icoFoam.C in a "compiler, please copy this source code here for me please"-manner. That is nice for code separation, but it is not nice for the indexer.

Question:
What if you copy the content of UEqn.H on top of "#include UEqn.H"? Does the indexer then recognise everything?

---

When I rebuild the index:
--> Project --> C++ Index --> Rebuild
Typically, my turbulence methods are not recognised, whereas I did include the appropriate files. Luckily, this magic trick automatically fixes this issue:
--> Project --> C++ Index --> Freshen all Files
Give it a try whenever you encounter a problem before trying anything else.

[giordy]

Hi,
In the icoFoam.C there is not "#include UEqn.H". The code is all in icoFoam.C and "createFields.H". I also tried to copy "createFields.H" in icoFoam.C but it showed the same errors.

My index are updated when i changed them. I don't have
--> Project --> C++ Index --> Rebuild


Maybe i am using a different version of eclipse.

Below my include, with fvCFD.H as first.

[giordy]

file:///C:\Users\szinna\Pictures\Capture.PNG

[floquation]

I use Eclipse Mars (4.5.1), however, that really shouldn't matter for this feature.

Try to access the Indexer functions as described here. Can you then find "Freshen all Files"?

[giordy]

Hi,

I tried to freshen all files and rebuild but no change.

I noticed that this part of the code does't give any issue, although i use "p" as well:

while (piso.correctNonOrthogonal())
{
// Pressure corrector
fvScalarMatrix pEqn
(
fvm::laplacian(rAU, p) == fvc::div(phiHbyA)
);
pEqn.setReference(pRefCell, pRefValue);
pEqn.solve(mesh.solver(p.select(piso.finalInnerIte r())));
if (piso.finalNonOrthogonalIter())
{
phi = phiHbyA - pEqn.flux();
}
}

[floquation]

Perhaps fvc::grad is not known then, since p does work in fvm::laplacian.
Are you able to open its declaration (F3)?
If correct, eclipse will give you multiple candidates, one of which is p's type: volScalarField.
If incorrect, it will show you no candidates that take a volScalarField as an argument --> the right fvc::grad is not known.

[giordy]

Hi,

I get the following possibilities for fvc:grad

1) grad(const GeometricField<Type,fvPatchField,volMesh> &):tmp<GeometricField<type,fvPatchField,volMesh >>
2) grad(const GeometricField<Type,fvPatchField,volMesh> &,const word &name &):tmp<GeometricField<type,fvPatchField,volMesh >>
3) grad(const GeometricField<Type,fvPatchField,surfaceMesh> &):tmp<GeometricField<type,fvPatchField,volMesh >>
4) grad(const tmp<GeometricField<Type,fvPatchField,volMesh>> &):tmp<GeometricField<type,fvPatchField,volMesh >>
5) grad(const tmp<GeometricField<Type,fvPatchField,volMesh>> &, const word & name):tmp<GeometricField<type,fvPatchField,volMesh >>
6) grad(const tmp<GeometricField<Type,fvPatchField,volMesh>> &):tmp<GeometricField<type,fvPatchField,volMesh >>

[giordy]

On the other hand if i look at the Console window, the solver build is finish without any error.