Re: [deal.II] Representing a void subdomain with a refined triangulation
Thanks, Wolfgang! What you describe makes perfect sense in case of Dirichlet BCs. However, I have no-flux (natural) BCs at the boundary between domains. I don't understand what to do with the cells in domain #2 to satisfy these? Additionally, would it be possible to further reduce the solution effort by constraining dofs inside domain #2 to zero? Best Alexander -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/26d11567-c83f-4a26-a02c-6518e00e3369%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Saving and retrieving solution vectors for adjoint based optimization
> I am doing an adjoint based optimization for which I solve a forward problem > and an adjoint. I need to save the forward solution at different time > instants and read it back to compute a gradient. What methods are available > to do this in deal.II ? The various vector classes have functions that can just dump the state of the vector into a file (the 'block_write/read()' functions), or you can serialize the whole vector via the serialization framework. (There is no tutorial program for serialization, but you can find examples of how this works in the tests/serialization/ directory). Alternatively, there is also the SwappableVector class that could help in your case. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/f336797d-4973-e46f-f67b-10f2cbeea02a%40colostate.edu. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "
On 6/17/19 1:50 AM, Muhammad Mashhood wrote: > I recently started working with deal.ii and want > to work with material models from material mechanics. For this so far I came > across nicely written and well worked code of "The 'Goal-oriented mesh > adaptivity in elastoplasticity problems " in the code gallery. I tried to > compile and run it on deal.ii 9.1.1 and one of the case ran but not giving > displacement and stresses values in the loading step output results. Can you be more specific what doesn't work? Which case is it that doesn't work? And what do you mean by "not giving displacement and stresses in the ... output"? 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/320cafda-7703-6ff3-78ba-e81aac47c5ff%40colostate.edu. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Representing a void subdomain with a refined triangulation
Alexander, > I have a triangulation which has been refined along some (polygonal) patch, > thus forming two non-overlapping domains (say, domain #1 and #2). My task is > to extract cells for domain #1, and solve BVP for this domain (with known > boundary conditions). The rest of the cells (domain #2) are not needed. An > example of such situation is shown attached (with land and ocean/sea being > two > domains). > > FWIW, the problem is posed in dim = 2, spacedim = 3. The solution is in H1. > > Here is what I struggle with: > > - I thought of using GridGenerator::create_triangulation_with_removed_cells, > but this one does not accept refined non-conforming meshes. Yes. You can't remove cells this way because then you would have (non-active) cells for which not all children are part of the mesh. That is not allowed. > - My next thought was to detect those edges, which domains #1 and #2 share > and > calculate face integrals on them during assembly, thus incorporating BCs. > Will > DoFTools::make_flux_sparsity_pattern be the right function for this? You mean you want to impose boundary conditions weakly? Like through the Nitsche method? You could do that. But you can also just impose them strongly. In essence, duplicate the functionality of the VectorTools::interpolate_boundary_values() function but instead of running it on only the faces at the boundary of the mesh, you run it also on the faces at the boundaries between the two subdomains. > - Next, what should I do on cells in domain #2? Logically, I should somehow > treat them with FE_Nothing... But how to get this done right? If you impose Dirichlet boundary conditions on the interface between the subdomains, then no knowledge of domain #2 leaks into domain #1. In other words, you can do whatever you please on domain #2. One option would be to just solve the same equation there -- you'd get something for the solution there, but you really don't care very much what exactly it is :-) If you wanted to reduce the numerical effort, you could just assemble a mass matrix on domain #2 instead of a stiffness matrix. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/f37acfeb-6897-31ab-5ea1-ed67e283d461%40colostate.edu. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Eigenproblem with Multithreaded Code
On 6/17/19 6:10 AM, Franco Milicchio wrote: > > we're about to implement an eigenvalue problem that needs multiple solutions. > In particular, we're going to compute min & max eigenvalues of several > matrices, so we were going to spawn some threads and solve some in parallel. > > The problem is that, as far as I see, there are wrappers in deal.II for > SLEPc, > so PETSc, but we cannot use MPI in our system. PETSc works only with MPI, and > I cannot start multiple threads, or at least that is what I understand (see > https://www.mcs.anl.gov/petsc/miscellaneous/petscthreads.html). I think that is only partially true. What is *not* safe is to let PETSc access the same data structures from multiple threads. That includes an MPI communicator. But if you are willing to duplicate the matrix and use different (cloned) MPI communicators for the copies of the matrix, then I suspect that you can use PETSc on multiple threads as long as every thread accesses only one of the matrices and a unique MPI communicator. That said, if you're already using MPI, why not just put one MPI process on each processor core? In that case, you don't need multithreading. 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/9498ebff-f086-bad9-d3a9-4db630b4e7ff%40colostate.edu. For more options, visit https://groups.google.com/d/optout.
[deal.II] Eigenproblem with Multithreaded Code
Dear all, we're about to implement an eigenvalue problem that needs multiple solutions. In particular, we're going to compute min & max eigenvalues of several matrices, so we were going to spawn some threads and solve some in parallel. The problem is that, as far as I see, there are wrappers in deal.II for SLEPc, so PETSc, but we cannot use MPI in our system. PETSc works only with MPI, and I cannot start multiple threads, or at least that is what I understand (see https://www.mcs.anl.gov/petsc/miscellaneous/petscthreads.html). Is there an alternative to SLEPc/PETSc for eigenproblems that is thread-safe? I don't know, Eigen, or others... Thanks! Franco -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/1d706dd4-4403-45ab-937f-4535df5a3030%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Sliding mesh-like approach using dealii
Dear Earl and Wolfgang, Thanks for the very thorough answer. I will definitely look into it this year and try to come up with a solution. I think there are many ways to tackle this type of approach using the existing tools :) I'll keep you informed should I find a way to make a decent implementation. Best! Bruno On Sunday, 16 June 2019 21:13:32 UTC-4, Wolfgang Bangerth wrote: > > > Bruno, > > > As some of you might know, sliding mesh approaches are generally used in > CFD > > simulation of rotating geometries without axial symmetry (for instance, > an > > impeller with baffles). > > This is generally achieved by having two triangulation, one that is > rotating > > and one that is static. At the interface between the meshes, constraints > are > > used to "bridge" the two meshes together. Although this generally > induces > > additional interpolation error, this is generally one of the best way to > deal > > with turbomachinery. > > > > Since dealii is already equipped to deal with contact problem, has > anybody > > ever investigated if a sliding-mesh type of simulation could be carried > out > > using dealii? > > I don't know, but then there are 1,200+ publications at >https://dealii.org/publications.html > that might contain something you're looking for. There's now even a search > function :-) > > There are going to be two challenges: > * Mesh generation. Earl Fairall already commented on that. > * Generation of the constraints. That's going to be difficult because >you'll have to find quadrature points on the faces of one mesh on the >faces of the other mesh, and these sorts of point search algorithms >are always expensive (though easy to parallelize). You need this kind >of mapping if you want to project between the two mesh surfaces; for >interpolation, you'll need to find the location of the support points >of the faces of one mesh on the faces of the other mesh, which is the >same kind of operation. > > You could consider a mortar approach in which you would have a third mesh > at > the interface. In that case, you could choose at least one of the meshes > involved to be somewhat structured, but in the end, it's probably going to > be > about as expensive as otherwise. > > I don't know anyone who has implemented the exact kind of application you > have, but you might want to look up some of the work done on > fluid-structure > interaction in deal.II (e.g., by Thomas Wick). I *believe* that they too > have > to interpolate between different kinds of meshes. There is also the > 'nonmatching' namespace that was added by Luca Heltai and coworkers in the > last release that helps you deal with overlay meshes -- which would also > be a > way to do what you're looking at -- the rotating geometry would simply be > an > overlay to a background mesh. I believe there is also a tutorial program > for that. > > Other than that, I have no real pointers. But it's an interesting topic, > and > if you find ways to implement what you are looking for, please feel free > to > post solutions here (and/or make small test programs available as code > gallery > or tutorial program! > > 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/3fdbf6a1-cd04-4e0d-82bd-859a032091e3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] Representing a void subdomain with a refined triangulation
Dear all, I have a triangulation which has been refined along some (polygonal) patch, thus forming two non-overlapping domains (say, domain #1 and #2). My task is to extract cells for domain #1, and solve BVP for this domain (with known boundary conditions). The rest of the cells (domain #2) are not needed. An example of such situation is shown attached (with land and ocean/sea being two domains). FWIW, the problem is posed in dim = 2, spacedim = 3. The solution is in H1. Here is what I struggle with: - I thought of using GridGenerator::create_triangulation_with_removed_cells, but this one does not accept refined non-conforming meshes. - My next thought was to detect those edges, which domains #1 and #2 share and calculate face integrals on them during assembly, thus incorporating BCs. Will DoFTools::make_flux_sparsity_pattern be the right function for this? - Next, what should I do on cells in domain #2? Logically, I should somehow treat them with FE_Nothing... But how to get this done right? Thanks! Alexander -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/6cdc5097-d5ac-4bb3-b229-dc9c74c1c3e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [deal.II] Undefined symbol related to BLAS and GSL in make test
Hi, ok, thanks for your input. It seems to be just a broken GSL installation. I downloaded GSL and compiled from source and everything seems to be working fine. Thanks, David On Mon, Jun 17, 2019 at 5:03 AM Wolfgang Bangerth wrote: > > David, > > > I recently tried to install deal.II. However, when I run make test, all > tests > > fails because of the following message > > > > > /home/gudrun/davidkl/Documents/dealii/build/tests/quick_tests/step.debug: > > symbol lookup error: /lib64/libgsl.so.23: undefined symbol: cblas_ctrmv > > > > In detail.log produces by cmake it looks like libgslcblas is correctly > found > > > > # DEAL_II_WITH_GSL set up with external dependencies > > #GSL_VERSION = 2.4 > > #GSL_INCLUDE_DIRS = /usr/include > > #GSL_USER_INCLUDE_DIRS = /usr/include > > #GSL_LIBRARIES = > /usr/lib64/libgsl.so;/usr/lib64/libgslcblas.so > > > > Furthermore, when I run the ldd command on the produced shared library > file > > something strange happens > > > > > > ldd lib/libdeal_II.g.so | grep gsl > > > > libgsl.so.23 => /lib64/libgsl.so.23 (0x7f6d7eb4f000) > > > > Hence, there is no libgslcblas linked. Should that be linked? > > Yes. If the GSL calls functions from the CBLAS, then the CBLAS should > really > also be linked. > > That's really a problem in the GSL, though. The libgsl.so should have > recorded > during installation that it relies on CBLAS, and if it had, then linking > with > libgsl.so would have automatically also pulled in libcblas.so. These sorts > of > problems are really obnoxious for us because they assume that the deal.II > installation system works around installation problems in the GSL. We > can't do > that for all of those broken libraries out there. The easiest approach is > to > install a version of GSL that has this fixed. > > > > The other strange thing is that in detail.log it says that it uses > > /usr/lib64/libgsl.so, but when I check which library it actually linked > to it > > is /lib64/libgsl.so.23, which is not in the same location as the one > printed > > in detail.log. > > > > On my system there is one GSL version in /lib64 (which is a shared > folder > > between many nodes), and one version in /usr/lib64, which is local on > one > > node. It appears like the GSL library that is used is not the one stored > in > > GSL_LIBRARIIES and that libgslcblas is not linked. > > > > Has anyone encountered similar problems? > > This is certainly awkward. Are you saying that on the front-end node of > the > cluster, the set of libraries available is different than on the compute > nodes? Where did you configure and compile deal.II, and where did you run > the > ldd commands for which you show output above? > > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/517ddf3a-909f-b350-1eba-97eb028e51e6%40colostate.edu > . > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/CAFA%3D84BMMXqPNWURjF_oN8AR84veaMrPAygH2xKNZ7gOR1SDPw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "
Dear deal.ii users, I recently started working with deal.ii and want to work with material models from material mechanics. For this so far I came across nicely written and well worked code of "The 'Goal-oriented mesh adaptivity in elastoplasticity problems " in the code gallery. I tried to compile and run it on deal.ii 9.1.1 and one of the case ran but not giving displacement and stresses values in the loading step output results. Anyone worked with it is warmly welcome to suggest or share any possible problem which I might not be taking care of? Thank you in advance! Regards, Muhammad -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/0212a592-4d00-4eab-aa24-84818ba9bda0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
