Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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/local/ to be used, what path do you want > to list first? > was not in my mind - since both are usually system pathes, where you typically need to have root-access. I thought on the case like PATH=/usr:/home/myuser/petsc (or the other way around). This case should be correctly detected by deal.II to pick up the user defined petsc lib and headers and not anything from the system pathes because of the order. I'm also not perfectly know, if it really is a deal.II-cmake detection problem (which I intended from the post of Timo) - or if it is "simple" wrong user environment (the former discussion in this thread). After the successful build of deal.II with candi, we state that the user have to either source all installed dependencies with the "enable.sh" bash script written by Timo or loading the runtime configuration with the (maybe out of the box imperfect) modulefile, before cmake / make / running a deal.II based application. This must be done at any time. Maybe that is the reason for the eclipse explanation of Daniel, which I do not really understand in the same way as Timo has answered (1st of the 3 above). Best Uwe -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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 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/local/ to be used, what path do you want to list first? The problem is that we just do #include #include for example. There is no way to provide further feedback at this point where to find each of these files -- the compiler just goes through its list of search paths. In some sense, that's just a broken system, but that's just how it is -- if you want multiple versions of the same package on your system, *all* of them have to be in separate directories outside where anything else lives. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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 > unavoidable. I'm not that sure about this last point. I'm using the environment modules packages (which is implemented for most of the linux and also macOS). But correctly sourcing of additional pathes (as we do this also in candi for a correct build) is more or less the same technique. 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. Can't we do something similar in the cmake detection of external packages? I'm not that expert in cmake, but I think that should be possible. Best Uwe -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Looking for more info on FE_RaviartThomas
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 from that former work - for the coupled Biot's poroelasticy problems up to now. On Thursday, August 31, 2017 at 9:23:07 AM UTC+2, Guido Kanschat wrote: > > > 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 are posed in > H^curl. > Exactly, I'm coming from electrical engineering - you usually need H^curl-, and not H^div-, conforming elements for the Maxwell equations. > I know that the dofs are certain moments on the faces and interior of the > > cell. But what are the test functions for these moments ? How can I get > > these test functions ? > > I just taught a course on mixed finite elements. Check out the > definition on page 97 here: > http://www.mathsim.eu/~gkanscha/notes/mixed.pdf > Thanks for sharing - I've added this to my lecture notes. Very nice work! On the faces, we have two different bases in deal.II: one using a > Legendre basis for Q_k, the other uses Lagrange interpolation in the > Gauss points on each face. I confess, I forgot how we did the > interior. > It's some time ago, where I've looked in detail in this implementation. When I remember correctly, there is some tensor-product type technique used on those one dimensional polynomials used for the interior, at least I'm stating that in my thesis on the implementation in deal.II of this element. Look for p. 124 and following here: http://edoc.sub.uni-hamburg.de/hsu/volltexte/2015/3112/ (the page is in german, but the thesis is written in english) The "other" interior (of the scalar variable) in deal.II is coming from using a FE_DG element in the sense of using a FiniteElementSystem. This is already explained in the belonging step tutorial of the instationary Stokes system). How I'm using it in my context, look for code line 181 at https://github.com/koecher/meat/blob/master/source/meat/MEAT_cG1.tpl.cc Hereby I'm using not the FE_DG element with equidistantly distributed support points, I'm using the support points coming from the Gauß-quadrature, since they typically have better physically relevant convergence properties (at least for linear elasticity / elastic wave propagation phenomena) The hole implementation works in my case without any special basis function transformations on general quad-meshes. Look for the test of numerical convergence on a distorted mesh (2nd numerical example) in our recently published open access publication: https://link.springer.com/article/10.1007%2Fs00211-017-0894-6 If you want to understand the mechanisms behind the choice of test and > shape function spaces, you cannot avoid the articles by Arnold, Falk, > and Winther on finite element exterior calculus. For rectangles, also > Arnold and Awanou, and Barnold, Boffi and Bonizzoni. > Indeed - read those references, they really help to understand this element. For the implementation of such spaces, you have two options: > > 1) Find out what the basis functions for the chosen node value set > look like and implement them directly. This would have been fairly > easy if we had had a strict tensor product concept and applied it. > Unfortunately, we didn't at the time. > Looks like that we need an Nedelec Element with continuous tangential face flux components (an not continuous normal components). Those type of element is (to my best knowlege) not implemented in deal.II, but looking at "the finite element periodic system" from the Fenics community: https://femtable.org/ They have this element implemented. (The Nc^e elements on quads). I think their implementation in deal.II can be done similar to our RT-element (which is a Nc^f element in that sense) implementation. You can find more on the finite element approximation of the Maxwell equations from the group of Prof. C. Wieners and Prof. W. Dörfler from KIT / University of Karlsruhe. They have recent publications, preprints and at least one recent doctoral thesis from S. Findeisen on that topic. But the implementation is done in an inhouse code (M++). Please note that all references of mine and the group I'm working in are already listed in the deal.II publication list. A shortcut can be found on my website: http://koecher.cc/uk/papers.php Kind regards Uwe -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To un
Re: [deal.II] Trouble getting UMFPACK to work
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 wrappers to UMFPACK are not compiled and you can't use it. Adding configuration options when you are configuring a step (or your code) is too late. Best, Bruno -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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 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 unavoidable. I would say that this setup (where there is a package in a default path, but you want to use one from a different path) is just fundamentally broken and can not reasonably be supported. That's awkward for Daniel, but hopefully he has access to a sysadmin who can either (i) remove the offending package, or (ii) update the offending package to include MUMPS support. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Trouble getting UMFPACK to work
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 be trying to run the commands elsewhere? Everything else in the code has been running just fine until it reaches the point it needs UMFPACK. Thank you for responding. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] crash with step-55 with PETSc both in serial and parallel
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:24 AM, Nur Fadel > wrote: > > Hi all, > > I have installed Deal II 8.5 and trunk versions on Daint (the CSCS > machine). > > When I run the example step-5 with PETSc I have the following error: > > Running using PETSc. > > Cycle 0: > >Number of degrees of freedom: 659 (578+81) > > > +-+++ > > | Total wallclock time elapsed since start| 0.354s | > | > > | || > | > > | Section | no. calls | wall time | % of total > | > > > +-+---+++ > > | assembly| 1 | 0.14s |40% > | > > | setup | 1 |0.0873s |25% > | > > | solve | 1 | 0.365s | 1e+02% > | > > > +-+---+++ > > ERROR: Uncaught exception in MPI_InitFinalize on proc 0. Skipping > > MPI_Finalize() to avoid a deadlock. > > > > Exception on processing: > > > > An error occurred in line <66> of file > > in > > function > > void > > > dealii::PETScWrappers::PreconditionerBase::vmult(dealii::PETScWrappers::VectorBase&, > > > > const dealii::PETScWrappers::VectorBase&) const > > The violated condition was: > > pc != nullptr > > Additional information: (none) > > > > Aborting! > > > > [0]PETSC ERROR: #1 PetscCommDestroy() line 214 in > > /project/csstaff/nfadel/petsc-vanilla/src/sys/objects/tagm.c > > [0]PETSC ERROR: #2 PetscHeaderDestroy_Private() line 116 in > > /project/csstaff/nfadel/petsc-vanilla/src/sys/objects/inherit.c > > > > on github I found the issue "step-55 PETSc fails #4150" already solved > but > > it seems not the same problem. > > > > I reproduce the crash both in serial and parallel, while trilinos works > > fine. > > > > The error is caught when Deal II checks if the pointer to preconditioner > > object's pc is a NULL. > > AssertThrow (pc != nullptr, StandardExceptions::ExcInvalidState ()); > > > > It happens when the minres solver does: > > precondition.vmult (v,*u[1]); > > > > Do you have any hint how to fix it? > > > > > > Thank you in advance! > > Nur > > > > > > -- > > The deal.II project is located at > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=naKdiC5MpUUon2ztgdpg6EXMaY_Y4siuEIMCo2REU-U&s=bkBgAEUtvkgVku1tMVte7BoHucoYxCvhYeXIy_OHMzU&e= > > > For mailing list/forum options, see > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_forum_dealii-3Fhl-3Den&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=naKdiC5MpUUon2ztgdpg6EXMaY_Y4siuEIMCo2REU-U&s=GdBkwqIdCUvJTldnuwEtrzs_3XawG9py6IWg74MwFdI&e= > > > --- > > You received this message because you are subscribed to the Google > Groups > > "deal.II User Group" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to dealii+un...@googlegroups.com . > > For more options, visit > https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=naKdiC5MpUUon2ztgdpg6EXMaY_Y4siuEIMCo2REU-U&s=iXMtDNGI9SX47AwdcwsJ6UoDB5XU5Ea9cnzidyZIZaE&e= > > . > > > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Trouble getting UMFPACK to work
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 > -DDEAL_II_WITH_UMFPACK=ON -DUMFPACK_DIR=/Downloads/deal.II/bundled/umfpack > ." and also "cmake -DDEAL_II_WITH_UMFPACK=ON > -DUMFPACK_DIR=/Downloads/deal.II/bundled/umfpack/UMFPACK ." and then > following each of these with "make" and "make run". Just to be sure: you did this in your deal.II build directory and you then compiled and installed deal.II, right? (using "make install") Please be sure that no other errors were reported in between. -- Timo Heister http://www.math.clemson.edu/~heister/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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=fVxmbdfreL4p1rCxGSP3IVICyedU6jM1ssJGagsPdZM&e= Something else must be wrong in his configuration. On Thu, Aug 31, 2017 at 1:06 PM, Timo Heister wrote: > 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=dIL3wBEPhKcZ12-PL_OQDXRtmH6p_Vzgxdj4W-7qBsE&s=eTejcjX6cyC0eg5obs1whEfIGxO-yIIYIs6o4ZxVVJg&e= > > So maybe this is not caused by -I /usr/include (from BZIP2) happening > before the PETSc path, but maybe because we now use -isystem for > includes and these are treated differently (as in not overwriting > /usr/include)? > > On Thu, Aug 31, 2017 at 12:49 PM, Timo Heister wrote: >>> 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 >> 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. >> >> -- >> Timo Heister >> http://www.math.clemson.edu/~heister/ > > > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ -- Timo Heister http://www.math.clemson.edu/~heister/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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=SLZp46kKykCBXKB5NsgAsszQFrf1t38lshuFDhzaVJ0&s=nuF_OPH4xZbpa7HceXxhfC-4AlCc5Ymv9tfaIJHPLH4&e= So maybe this is not caused by -I /usr/include (from BZIP2) happening before the PETSc path, but maybe because we now use -isystem for includes and these are treated differently (as in not overwriting /usr/include)? On Thu, Aug 31, 2017 at 12:49 PM, Timo Heister wrote: >> 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 > 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. > > -- > Timo Heister > http://www.math.clemson.edu/~heister/ -- Timo Heister http://www.math.clemson.edu/~heister/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
> 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 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. -- Timo Heister http://www.math.clemson.edu/~heister/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Combining Taylor-Hood and Raviart Thomas spaces with hp::FECollection
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. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Trouble getting UMFPACK to work
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
in function
void dealii::SparseDirectUMFPACK::factorize(const Matrix&) [with Matrix
= dealii::SparseMatrix]
The violated condition was:
false
The name and call sequence of the exception was:
ExcMessage("To call this function you need UMFPACK, but configured
deal.II without passing the necessary switch to 'cmake'. Please consult the
installation instructions in doc/readme.html.")
Additional Information:
To call this function you need UMFPACK, but configured deal.II without
passing the necessary switch to 'cmake'. Please consult the installation
instructions in doc/readme.html.
Stacktrace:
---
#0 /Downloads/deal.II/lib/libdeal_II.so.8.0.0: void
dealii::SparseDirectUMFPACK::factorize
>(dealii::SparseMatrix const&)
#1 step-3: TmsProblem::solve()
#2 step-3: TmsProblem::run()
#3 step-3: main
Aborting!
CMake Error at CMakeFiles/run_target.cmake:6 (MESSAGE):
Program terminated with exit code: 1
CMakeFiles/run.dir/build.make:57: recipe for target 'CMakeFiles/run' failed
make[3]: *** [CMakeFiles/run] Error 1
CMakeFiles/Makefile2:264: recipe for target 'CMakeFiles/run.dir/all' failed
make[2]: *** [CMakeFiles/run.dir/all] Error 2
CMakeFiles/Makefile2:271: recipe for target 'CMakeFiles/run.dir/rule' failed
make[1]: *** [CMakeFiles/run.dir/rule] Error 2
Makefile:196: recipe for target 'run' failed
make: *** [run] Error 2
I have tried "*cmake -DDEAL_II_WITH_UMFPACK=ON*" and "*cmake
-DDEAL_II_WITH_UMFPACK=ON -DUMFPACK_DIR=/Downloads/deal.II/bundled/umfpack
.*" and also "*cmake -DDEAL_II_WITH_UMFPACK=ON
-DUMFPACK_DIR=/Downloads/deal.II/bundled/umfpack/UMFPACK .*" and then
following each of these with "*make*" and "*make run*". However, all of
these still end up giving me the same error as above. Can anyone help me
with getting umfpack to work? Thank you in advance.
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Combining Taylor-Hood and Raviart Thomas spaces with hp::FECollection
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 06:19 AM, Eldar Khattatov wrote: > > It tries to compare FE_RaviartThomas. This element indeed does not > implement > > compare_for_face_domination() function, > > Correct. Though you could think about implementing it. > > > > so I tried using FE_RaviartThomasNodal > > instead, as it provides an implementation for this function. > Unfortunately, > > from what I understood from the implementation in RT_Nodal, it works > only if > > another element in the comparison is also of the same type RT_Nodal, > otherwise > > it has same Assert(false, ...) before return statement, > > Yes, indeed. But it shouldn't be very difficult to extend it for the > particular case you are considering: that the other element is an > FE_Nothing. > The FE_Nothing describes a field that is constant zero, and so the > appropriate > interface condition is that the FE_RT_Nodal should also be zero at that > interface, or be left unconstrained, depending on how you want the > FE_Nothing > to be interpreted. That should be easy to implement. > > Take a look at how the FE_Q element does this, in one of the classes that > sit > below class FiniteElement and class FE_Q in the class inheritance diagram. > I > think you'll see pretty quickly how you want to implement things for your > case. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Re: Lagrange multipliers
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, (where epsilon some very small number not to affect your theoretical accuracy) to your system (so it becomes nonsingular). This is not the most efficient way of doing it, but it is very easy as Deal.II has everything you need for this approach out of the box. Best, Eldar On Tuesday, August 8, 2017 at 1:16:28 PM UTC-4, neverwoke wrote: > > Hello all. I am very new to the community but very eager to learn. I am > wonder if there is an out-of-the-box support for using Lagrange multipliers > on a boundary, to enforce rigid body motion in Stokes flow, similar to the > work of Glowinski [1] or Hwang [2]? > > [1] Glowinski, R., Pan, T. W., Hesla, T. I., Joseph, D. D., & Periaux, J. > (2001). A fictitious domain approach to the direct numerical simulation of > incompressible viscous flow past moving rigid bodies: application to > particulate flow. *Journal of Computational Physics*, *169*(2), 363-426. > [2] Hwang, W. R., Hulsen, M. A., & Meijer, H. E. (2004). Direct > simulation of particle suspensions in sliding bi-periodic frames. *Journal > of Computational Physics*, *194*(2), 742-772. > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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 & include paths for deal/petsc/trilinos/... in the settings. My projects compile and also use code inside the PETSC_HAVE_MUMPS flags. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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 presume from what you said earlier its in /usr/[include/lib]? but still it prefers the one in /usr/include/) On Thursday, August 31, 2017 at 3:44:08 PM UTC+2, Jean-Paul Pelteret wrote: > > @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/petsc-3.7.6 >> #PETSC_INCLUDE_DIRS = >> /home/djodlbauer/deal.ii-candi/petsc-3.7.6/include;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/include >> #PETSC_USER_INCLUDE_DIRS = >> /home/djodlbauer/deal.ii-candi/petsc-3.7.6/include;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/include >> #PETSC_LIBRARIES = >> /home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libpetsc.so;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libcmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libdmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libsmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libzmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libmumps_common.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libpord.a;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/lib/libparmetis.so;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/lib/libmetis.so;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libHYPRE.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libscalapack.a;/usr/lib64/liblapack.so;/usr/lib64/libblas.so;/usr/lib64/libssl.so;/usr/lib64/libcrypto.so;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_usempi.so;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_mpifh.so;gfortran;quadmath;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_cxx.so;m;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi.so;pthread;dl > > > I didn't see anything wrong, but maybe I overlooked something. > > J-P > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
@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/petsc-3.7.6 > #PETSC_INCLUDE_DIRS = > /home/djodlbauer/deal.ii-candi/petsc-3.7.6/include;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/include > #PETSC_USER_INCLUDE_DIRS = > /home/djodlbauer/deal.ii-candi/petsc-3.7.6/include;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/include > #PETSC_LIBRARIES = > /home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libpetsc.so;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libcmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libdmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libsmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libzmumps.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libmumps_common.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libpord.a;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/lib/libparmetis.so;/home/djodlbauer/deal.ii-candi/parmetis-4.0.3/lib/libmetis.so;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libHYPRE.a;/home/djodlbauer/deal.ii-candi/petsc-3.7.6/lib/libscalapack.a;/usr/lib64/liblapack.so;/usr/lib64/libblas.so;/usr/lib64/libssl.so;/usr/lib64/libcrypto.so;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_usempi.so;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_mpifh.so;gfortran;quadmath;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi_cxx.so;m;/usr/lib64/mpi/gcc/openmpi/lib64/libmpi.so;pthread;dl I didn't see anything wrong, but maybe I overlooked something. J-P -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
> 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 use the correct Petsc installation? Weird, it should already do that. Can you provide us with your detailed.log from candi/tmp/build/deal.*/ ? It should list the correct PETSc paths. -- Timo Heister http://www.math.clemson.edu/~heister/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] PETSC_HAVE_MUMPS not set correctly ?
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. When compiling my code (using eclipse), it choses the correct version. Since I have no root access, I cannot remove the old version of petsc. Is it possible to somehow force deal.II to use the correct Petsc installation? (PETSC_DIR/INCLUDE/LIB ... are all pointing towards the correct installation, but still it prefers the one in /usr/include/) Thanks for pointing me into the right direction! Best regards, Daniel -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Computing the curl of a solution vector field obtained from Nedelec elements at receiver locations
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 (secondary plus primary) and > magnetic field (coef* curlE) I am not sure what the terms "primary" and "secondary" fields mean. If they are electric field and electric displacement, be aware that they are in different function spaces! > 2) The other option is to follow the advice by Ross Kynch, and have loop over > cells, quadrature points and dofs to get local contributions to total > electric and magnetic field. > In this case I am not sure how then I get a global vector. When you do this, please do not forget the de Rham complex: the curl of a Nedelec element is a Raviart-Thomas element. So, if you do the postprocessing, you should either choose such an element to store your values, or a DG element containing the Raviart-Thomas space. Best, Guido -- Prof. Dr. Guido Kanschat Interdisziplinäres Zentrum für Wissenschaftliches Rechnen Universität Heidelberg Im Neuenheimer Feld 368, 69120 Heidelberg -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Looking for more info on FE_RaviartThomas
> 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: 1) Test functions on the faces can be transformed as is (as scalars, no special transformation). This will still make the degrees of freedom on both sides of the face coincide and you retain normal continuity. 2) Test functions in the interior are 1-forms. Therefore, they transform like the gradients of a scalar function. > A basic question. If I have a solution vector in FE_RaviartThomas, then the > dofs are the moments, right ? Or, are they nodal values ? They are 1) The moments with respect to a Legendre basis of Q_k on the faces 2) The moments with respect to a Legendre basis of the Nedelec element in the interior Best, Guido -- Prof. Dr. Guido Kanschat Interdisziplinäres Zentrum für Wissenschaftliches Rechnen Universität Heidelberg Im Neuenheimer Feld 368, 69120 Heidelberg -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Looking for more info on FE_RaviartThomas
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 are posed in H^curl. > I know that the dofs are certain moments on the faces and interior of the > cell. But what are the test functions for these moments ? How can I get > these test functions ? I just taught a course on mixed finite elements. Check out the definition on page 97 here: http://www.mathsim.eu/~gkanscha/notes/mixed.pdf It's Definition 4.2.35. What you see is that the test functions are the space Q_k on the faces and the Nedelec elements in the interior. Note that the definition is with respect to test function spaces, not to actual test functions. For that, you have to choose a basis for these spaces. On the faces, we have two different bases in deal.II: one using a Legendre basis for Q_k, the other uses Lagrange interpolation in the Gauss points on each face. I confess, I forgot how we did the interior. If you want to understand the mechanisms behind the choice of test and shape function spaces, you cannot avoid the articles by Arnold, Falk, and Winther on finite element exterior calculus. For rectangles, also Arnold and Awanou, and Barnold, Boffi and Bonizzoni. When it comes to general quadrilaterals, search for the Piola transform in my notes. And for an in-depth analysis of convergence, the articles by Arnold, Boffi, and Falk. I am not completely d'accord with their conclusions, since I see the divergence of RT_k in the dual of Q_k, and those spaces do not naturally coincide on general quadrilaterals. > Also what do the shape functions look like ? Let me explain 2D. 3D is analogous. We have two shape function sets for each direction. The shape functions for the x-component of the vector associated with the two vertical faces are tensor products between the basis in y (Legendre or Lagrange as described for the test functions above) and polynomials in x such that they are one on this face, zero on the other and all interior degrees of freedom vanish. Similarly, you define basis functions for interior degrees of freedom. Then you do the same for the y-component, switching x and y. > I am looking for some references where I can read more about this space, wrt > how it is implemented in deal.II For the implementation of such spaces, you have two options: 1) Find out what the basis functions for the chosen node value set look like and implement them directly. This would have been fairly easy if we had had a strict tensor product concept and applied it. Unfortunately, we didn't at the time. 2) you take a convenient basis (Monomials, Legendre, Lobatto), then you apply each node functional to each basis function, which gets you a square matrix. Applying the inverse of this matrix to the vector of the original basis functions, you get the basis you want. This is, what I implemented at least for the non-nodal version. I hope this helps for the moment. Best, Guido -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
