Dear Wolfgang,
the case you describe:
Imagine you had two different versions of PETSc installed in /usr/ and
> /usr/local/, and you had two different versions of Trilinos installed in
> /usr/ and /usr/local/. If you want the version of PETSc in /usr and the
> version of Trilinos from
In any case, the given strings in search pathes have an order
(not sure in which direction), but you can easily "overwrite" a system
path like
/usr/bin by adding it in front or at the back.
Imagine you had two different versions of PETSc installed in /usr/ and
/usr/local/, and you had two
Dear Wolfgang
I don't think there is anything you can do about this situation at some
> fundamental level. If some of our dependencies are in /usr/include, you
> need to have that path accessible. The fact that you may find other
> dependencies there as well if they have been installed there
On 08/31/2017 10:49 AM, Timo Heister wrote:
Huh, that makes sense. How would we protect against that though? Two
suggestions:
1. if a path is /usr/include or any other default search path, don't add them
2. Sort the include paths and make sure the system path comes after
all the other ones.
I
Timo,
I do eventually plan on updating the code to the latest release.
I was doing the commands inside a folder in deal.II (similar to if I was in
deal.II/examples/step-1). I already have deal.II installed and compiled. I
have been going through a few of the examples perfectly fine. Should I
Sorry, for the late answer,
I haven't setup Hypre, this is the problem!
Thanks!
Nur
Il giorno domenica 13 agosto 2017 18:25:14 UTC+2, Timo Heister ha scritto:
>
> Nur,
>
> do you have PETSc configured without hypre by any chance? step-55 runs
> correctly for me.
>
> On Fri, Aug 11, 2017 at
John,
> I am currently using Deal II version 8.0.0.
I would like to encourage you to update to the latest release. Many
things have changed and improved over the years. That probably also
includes handling of dependencies like UMFPACK.
> I have tried "cmake -DDEAL_II_WITH_UMFPACK=ON" and "cmake
and I take that back, we are not using -isystem:
Interesting note: apparently cmake should already filter out this
default include path:
> Maybe the order of the includes is a problem, since there are some libraries
> being picked up from standard locations:
>
>> #BZIP2_INCLUDE_DIRS = /usr/include
>> #BZIP2_LIBRARIES = /usr/lib64/libbz2.so
Huh, that makes sense. How would we protect against that though? Two
On 08/31/2017 08:55 AM, Eldar Khattatov wrote:
Thank you for the answer, it was indeed very easy to modify the RT_Nodal
according to your comments. If this patch could be of use to the
library/community I can commit my changes to the repo.
Yes, please do open a pull request for this!
Best
Hello everyone,
I am currently using Deal II version 8.0.0. When I try to run a project I
am getting the following:
Exception on processing:
An error occurred in line <379> of file
Thank you for the answer, it was indeed very easy to modify the RT_Nodal
according to your comments. If this patch could be of use to the
library/community I can commit my changes to the repo.
Best,
Eldar
On Friday, August 18, 2017 at 6:23:31 PM UTC-4, Wolfgang Bangerth wrote:
>
> On
One way of using Lagrange multipliers on the boundary is to have an
additional full dimensional space for them. With this you will be able to
compute the boundary terms, but you will need to restrict the interior DOFs
of this space by adding something like:
(epsilon * lambda, mu)_Omega,
Maybe the order of the includes is a problem, since there are some
libraries being picked up from standard locations:
#BZIP2_INCLUDE_DIRS = /usr/include
> #BZIP2_LIBRARIES = /usr/lib64/libbz2.so
Daniel, where is this other installation of PETSc located on your system? I
@timo
Can you provide us with your
> detailed.log from candi/tmp/build/deal.*/ ?
>
Daniel already did so in the 4th post in this thread:
#DEAL_II_WITH_PETSC set up with external dependencies
> #PETSC_VERSION = 3.7.6.0
> #PETSC_DIR =
> When compiling my code (using eclipse),
> it choses the correct version.
That doesn't make sense. Eclipse will just run "make". Or are you
referring to the syntax highlighting?
> Since I have no root access, I cannot remove the old version of petsc. Is it
> possible to somehow force deal.II to
Indeed, there was a previous installation on my system configured without
Mumps which I have not noticed so far.
It seems that during installation of deal.II, it compiled against this
version instead of the one installed via candi, despite showing the correct
include/library paths during
Dear Anna,
> I have successfully computed the secondary electric field for 3D case as
> described in the paper by Grayver, 2014. These field is declared as
> BlockVector solution, where the block correspond to real and
> imaginary parts.
> Now I would like to compute total electric E
19 matches
Mail list logo
