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 /usr/loca
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 d
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 is
Dear Praveen,
Dear Guido and Wolfgang,
to additionally support this discussion, I have some remarks here. I'm
using the
RT-spaces for the diffusion equation (i.e. a heat equation with H^div
conforming flux
for local mass conservation between elements, which is needed in porous
media flow).
And
John,
On Thursday, August 31, 2017 at 3:52:44 PM UTC-4, John wrote:
>
>
> I was doing the commands inside a folder in deal.II (similar to if I was
> in deal.II/examples/step-1).
>
That won't work you need to reconfigure, recompile, and reinstall deal.II
to get UMFPACK to work. Otherwise, the wra
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 d
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 b
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 7:
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:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_dealii_dealii_pull_3897&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=dIL3wBEPhKcZ12-PL_OQDXRtmH6p_Vzgxdj4W-7qBsE&s=fVxmbdfreL4p1
Interesting note: apparently cmake should already filter out this
default include path:
https://urldefense.proofpoint.com/v2/url?u=https-3A__gitlab.kitware.com_cmake_cmake_issues_16291&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=SLZp46kKykC
> 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
W.
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 08/18/2017
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, (whe
I think the old petsc headers are in /usr/include/, libs in /usr/lib64/ as
far as I remember (will check tomorrow).
That doesn't make sense. Eclipse will just run "make". Or are you
> referring to the syntax highlighting?
>
I use the internal builder from Eclipse, and entered all library & inc
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 = /home/djodlbauer/deal.ii-candi
> 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 cmake.
Dear Anna,
> I have successfully computed the secondary electric field for 3D case as
> described in the paper by Grayver&Buerg, 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 (sec
> On Cartesian grids I have used FE_RaviartThomasNodal and defined my own test
> functions. But on quad meshes, there is this Piola transform that comes in,
> and I dont understand what are the test functions in this case.
I think you should be able to choose your basis by face/cells. That means:
Dear Praveen,
> Now I would like to solve Maxwell equations on general quad meshes. For this
> I have to use FE_RaviartThomas, but I do not completely understand this
> space.
This statement is puzzling, since Raviart-Thomas elements are for
H^div, while at least what I consider Maxwell problems
24 matches
Mail list logo