Re: [deal.II] Assemble system slowing down the program

Hi Wasim, It looks like you're passing your solution vector by copy for each cell that you're assembling on. You probably want to pass it by reference. Best, Jean-Paul Sent from my mobile device. Please excuse my brevity and any typos. On Sun, 08 Jan 2023, 14:38 Wasim Niyaz Munshi ce21d400, <

Re: [deal.II] How to access variables in the postprocessor object

Hi Raul, The “input_data” argument to the evaluate_vector_field() function has a method that can be called to retrieve the cell that is currently being processed: https://dealii.org/developer/doxygen/deal.II/structDataPostprocessorInputs_1_1CommonInputs.html#a2bc88342acd8e41314c8c1328bd98a67

Re: [deal.II] Principal stress components

Hi Raul, I’m a bit late to the discussion, but maybe this piece of information might still be useful to you. There is a function that computes and returns the eigenvalues and eigenvectors of symmetric tensors:

Re: [deal.II] Looking for clarification on a few places on Step-44

Hi Matthew, I'm glad that you find step-44 to be a useful tutorial! Let me try to answer your questions directly. /My first question deals with the statement "The Euler-Lagrange equations corresponding to the residual"/ / / /Directly above this sentence is the residual, whose

Re: [deal.II] Stress in cylindrical coordinate system

Dear Johanna, What you describe here makes sense. Such a transformation is described at this link (see section 2.7 "Converting tensors between Cartesian and Spherical-Polar bases". I think that

Re: [deal.II] automatic differentiation:

gt; C = symmetrize(F^t *F); > ad_helper.register_independent_variable(C, C_dofs); > const SymmetricTensor<2, dim, ADNumberType> C_ad = > ad_helper.get_sensitive_variables(C_dofs); > > Best, > Simon > > > > Am Mo., 18. Juli 2022 um 22:46 Uhr schrieb Jean-Paul Pelteret <

Re: [deal.II] fourth-order referential deviatoric tensor Dev_P: why is 'S' used in the definition?

Hi Simon, If you compare Holzapfel's definition with that of Wriggers, for instance, one notices the difference in how they define this 4th-order identity tensor. This particular term comes from the derivative d*C*/d*C* (i.e. differentiating a [symmetric] tensor w.r.t itself), and if you do

Re: [deal.II] Installation problem using spack

Hi Marco, I've open a PR in Spack (https://github.com/spack/spack/pull/32079) that backports the patches that we added to the development version to 9.4. Feel free to try it and provide some feedback as to whether or not it works for you. Best, Jean-Paul On Thursday, August 11, 2022 at

Re: [deal.II] automatic differentiation:

Hi Simon, Unfortunately I don’t have the time at this moment to give you a full explanation as to why the logic of your code is wrong, but in essence you have the sequence of operations inverted. You need to compute your energy based on the “sensitive” DoF values that would come from the

Re: [deal.II] RHS function represented by an interpolation

Hi Alexander, The answer that Wolfgang gave is the one that you want to follow. But I can give some input into your one question. > The problem here is the step 3: somehow I need to specify the same geometric > cell for two FEValues with different finite element systems while preserving > the

Re: [deal.II] 3D Periodic BCs

Hi Jack, The message that you’re seeing after fixing your first problem using Daniel’s advice is being emitted from your own code. Specifically, the set_neumann_bc() function in the class RMHD::Entities::VectorBoundaryConditions. You’ll have to inspect your code more carefully to understand

Re: [deal.II] error: installation of dealii using spack

Hi Simon, Daniel is right — only Sundials versions 5 through 5.8 are compatible with deal.II 9.3.2, while Sundials 6 is compatible with 9.3.4 onwards. This is in fact what is stated in the Spack package, so I don’t quite know how it is that you’re able to get this mixed configuration:

Re: [deal.II] Can Class DataPostprocessor access cell of triangulation?

Dear Chen, Would it be correct to say that you’ve implemented a class that derives from DataPostprocessor[Scalar,Vector,Tensor] and that you’re wanting to access the cell from your overriding implementation of evaluate_[scalar,vector]_field()? If so, then take a look at the

Re: [deal.II] Supported matrix/vector to LinearOperator

Dear Chen, Bruno pointed you to the exact example that I was going to. It is certainly possible to use linear operators as preconditioners for solvers. It looks like support for TrilinosWrappers::SolverDirect has not yet been implemented:

Re: [deal.II] Error using Operator/ in Vector and FullMatrix

Hi Raghunandan, I think that you misinterpreted the documentation: operator/= is implemented for the Vector class and operator*=

Re: [deal.II] Problem about cell iterator

Dear Toddy, This is a link to the documentation, where this function (a class constructor) is explained in more detail https://dealii.org/current/doxygen/deal.II/classDoFAccessor.html#a8d14894a737bb1edf3719e4de058a284

Re: [deal.II] Problem about cell iterator

Hi Toddy, It’s possible to convert a triangulation iterator to a DoF iterator using the technique described here: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators

Re: [deal.II] Efficient Matrix-based Calculation

Dear Masoud, > As you mentioned, we expect this to be slower than the equivalent code in > step-8; however, it is very slower than the same code that I wrote before in > Matlab. A quick question: are you sure that you’re running your problem in release mode, rather than debug mode? I had a

Re: [deal.II] Mathematical clarification for step-44

Hi Arnold, When I compare the documentation to step-44 that you quote to the code itself, it would seem like there’s a typo there. The second term “-2 p \mathcal{I}” of the part that underlined should actually read “-2 p \mathcal{S}” since this really is the symmetric fourth order identity

Re: [deal.II] Implementing a fiber reinforcement in a biphasic model

Hi Matt, As a supplement what David already mentioned, I used the QP-based approach that you laid out for skeletal muscle modelling. Although the code-related implementation details are not documented in my dissertation , the Linear Elastic Active

Re: [deal.II] Massively parallel & inverse matrix solver

Dear Hermes, The equivalent classes to SparseDirectUMFPACK for parallel linear algebra would be: - TrilinosWrappers::SolverDirect : You can choose the implementation through the AdditionalData

Re: [deal.II] Coarsening grid from Abaqus imported mesh

Dear Truong, To supplement Bruno’s remarks, and answer this question in particular: > I guess a procedure like associating the surface boundaries (from meshing > software) to the manifolds would also only works for meshing refinement, not > for mesh coarsening. It would work for mesh

[deal.II] Re: Boost version problem

Hi Lucas, The documentation that describes how to configure CMake options for external libraries is here: https://dealii.org/developer/users/cmake_dealii.html#configureext . You should just need to pass cmake the flag -DBOOST-DIR= (with the correct path added, of course. From your first post,

Re: [deal.II] How to implement an orthotropic material on differnet parts

Hi Ibrahim, My guess is that the mesh has been exported without the connectivity between the parts being enforced. So even though the physical vertices of the mesh overlap where you have different parts, there are two or more distinct vertices that lie on top of one another and the

Re: [deal.II] point_value, Real parts, step-29

Another thing: You probably also need to initialise with the right number of components. So something like Vector vecSol (fe.n_components()); > On 10. Aug 2021, at 19:40, Jean-Paul Pelteret wrote: > > Hi Hermes, > > You don’t say what errors you’re seeing, but my guess is that

Re: [deal.II] point_value, Real parts, step-29

Hi Hermes, You don’t say what errors you’re seeing, but my guess is that it now doesn’t compile. This variant of the function (the one that Daniel linked to) returns void, so you should call it before outputting the result: Vector vecSol; VectorTools::point_value(dof_handler,

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

me references on this > topic, I would appreciate that very mush. > > You’re totally right, it converges only if a very small load step is used. > The residual grows up fast and the result is meaningless if the load > increment is large. > > Thanks for your great help! >

Re: [deal.II] Able to use umfpack in debug configuration, but not in release configuration

Hi Lucas, I’m glad that you managed to solve this issue yourself. > Given that the problem was a silly mistake on my end, ought I delete the > forum post? Given that you’ve explained what you did to fix the problem, this is useful information for all. So we’ll leave the thread in place just

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

s::F(grad_u); > …………. > } >……….. > } > ……….. > } > > Can you tell me what’s wrong with the code above? > > Thank you! > Michael > > > From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com> > Sent: Sunday,

Re: [deal.II] profiling and parallel performance of deal.II user codes

To add to this great list of tools (which we should document on our Wiki), there’s also the LIKWID performance monitoring and benchmarking suite which is able to provide some very low-level metrics and tools to help benchmarking. https://github.com/RRZE-HPC/likwid

Re: [deal.II] Computing the solution gradient at the quadrature point on a face

Hi Michael, The problem here is that “scratch.solution_grads_u_total” is initialised with the cell FEValues, and so has n_cell_quadrature_points entries. You need to pass "scratch.fe_face_values_ref[u_fe].get_function_gradients(scratch.solution_total, scratch.solution_grads_u_total);”

Re: [deal.II] 'make' returns error on step-1 example

Dear Wakil, I’m glad that you were able to solve this issue. It (the inclusion of this libdl.tbd library) is something that we have noticed, and are still actively trying to address to make the Mac package as robust as possible. May I ask, how did you solve the problem? It’s clear that you

Re: [deal.II] Matrix Multiplication

r&) [with > DoFHandlerType = dealii::DoFHandler<2, 2>]’ is deprecated > [-Wdeprecated-declarations] > 1136 | DoFTools::count_dofs_per_block(dof_handler_ref, dofs_per_block, > | ~~^ > 1137 |

Re: [deal.II] Matrix Multiplication

ng tensor notation but just have no idea how to do that. > > <991EE976D38946F2A751BB07719E062B.png> > > Thanks, > Michael > > > From: Jean-Paul Pelteret <mailto:jppelte...@gmail.com> > Sent: Wednesday, July 21, 2021 10:45 PM >

Re: [deal.II] Deal.II programming environment

Hi Martin, This is the sort of case where where VSCode is really useful. It has an easy to use remote development extension, where you would open and use the editor in Windows but you’d be editing and building files on the virtual machine. Here are a couple of official links that explain the

Re: [deal.II] Matrix Multiplication

Dear Michael, The classes that better serve your purpose are the Tensor and SymmetricTensor classes: https://dealii.org/current/doxygen/deal.II/classTensor.html https://dealii.org/current/doxygen/deal.II/classSymmetricTensor.html

Re: [deal.II] How to add 2nd iterator to MeshWorker::mesh_loop ?

To add to what Wolfgang has already said, there’s this entry in our FAQ on this topic: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#can-i-convert-triangulation-cell-iterators-to-dofhandler-cell-iterators

Re: [deal.II] Map from dof index to vertex index

To add to what Wolfgang has already said, there’s this entry in our FAQ on this topic (well, the reverse mapping from vertex to DoF): https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#how-do-i-get-the-degree-of-freedom-indices-at-vertices

Re: [deal.II] New location for sacado.hpp

> Thank you for all your help resolving this issue. > > > > On Wednesday, 7 July 2021 at 14:36:36 UTC-4 Jean-Paul Pelteret wrote: > Hi again Matthew, > > I’ve also found this build log for the Debian deal.II apt package > https://buildd.debian.org/status/fet

Re: [deal.II] New location for sacado.hpp

try. Best, Jean-Paul > On 7. Jul 2021, at 20:15, Jean-Paul Pelteret wrote: > > Hi Matthew, > > If you look at either log file, then you’ll see that Trilinos was in fact not > detected for some reason. > >> DEAL_II_WITH_TRILINOS = OFF > > > I’m no

Re: [deal.II] New location for sacado.hpp

headers in my > /usr/include/trilinos directory. Just skimming the summary file it appears > that deal.II did not detect sacado. Not sure why not though. > > Thanks for the tip on the new tutorials. I will check them out once I get > this working. > > Matt > > On

Re: [deal.II] New location for sacado.hpp

Hi Matthew, I don’t quite understand exactly how you installed deal.II and Trilinos. Perhaps you can provide some more explicit details so that we can help you out. * Is Trilinos installed using the apt package, and deal.II installed from source? If you built deal.II from source, may you

Re: [deal.II] On the discretization of the time harmonic Maxwell equation

Hi Abbas, I’m sorry that nobody has answered your question to date. It could be that there is no-one on the forum with the requisite knowledge to help you, or maybe those that have the knowledge just aren’t capable of responding at the moment. If you haven’t done so already, then perhaps you

Re: [deal.II] Saving PointHistory data to file for restart

Hi Dario, To add to what’s already been suggested, you can also look at the TransferableQuadraturePointData and ContinuousQuadratureDataTransfer

Re: [deal.II] Using periodic boundary conditions with parallell processing

Hi Raghunandan, Quick question: This sort of setup sounds like something that you would do for homogenisation problems… Have you fixed your periodicity frame? (This amounts to completely fixing one point to remove rigid body translations, and partially constraining n-dim other points to remove

Re: [deal.II] Questions on Step-18

98a, title = {Continuum Mechanics: Concise Theory and Problems}, publisher = {Dover Publications Inc.}, year = {1998}, author= {Chadwick, P.}, address = {Mineola, New York, USA}, edition = {2$^{\text{nd}}$}, isbn = {9780486401805}, owner = {Jean-Paul Pelteret},

Re: [deal.II] Parallelizing a code with Linear Operators and Packaged Operations

Hi Kubra, Someone asked a similar question just a few day ago, so I have some information pre-prepared for you. LinearOperators do support Trilinos linear algebra classes, but there is no implementation for PETSc yet. The documentation is lacking a little bit in explaining how to use the

Re: Messaggio privato su: [deal.II] step-17: MPI parallelisation doesn't run (macOS Catalina)

Hi Bob, I’ve copied your message to me back onto the mailing list. Yes, as you observed you need to use the terminal that opens when you run the deal.II application. I’m glad that you figured this out. When you run the app, it sets up the local environment (for that specific terminal instance)

Re: [deal.II] Questions on Step-18

ocity (), since ? > > Can you check this as well? > > > Best, > Michael > > > > > > > On Sat, Jun 26, 2021 at 1:48 AM Jean-Paul Pelteret <mailto:jppelte...@gmail.com>> wrote: > Following Andrew’s explanation, I suppose

Re: [deal.II] step-17: MPI parallelisation doesn't run (macOS Catalina)

Hi Bob, I think that for anyone to be able to try to help diagnose the source of this problem, they’d have to know the specifics about the way that you’ve installed deal.II. Are you using the Mac package, or have you built deal.II from source? If the latter, then can you please provide us with

Re: [deal.II] Questions on Step-18

Following Andrew’s explanation, I suppose that this is relation for which we’re lacking the factor of 1/2, right? https://en.wikipedia.org/wiki/Angular_velocity#Angular_velocity_as_a_vector_field If so, then

Re: [deal.II] Questions on Step-18

velocity gradient is the vorticity > which is twice the angular velocity - hence I think you need a 1/2. Happy to > be corrected on this. > > Best, > Andrew > > > On 24 Jun 2021, at 21:03, Jean-Paul Pelteret <mailto:jppelte...@gmail.com>> wrote:

Re: [deal.II] Deal.II compilation error issued at example steps phase

Dear Saad, Well, after briefly browsing the Ginkgo repository online, its a bit of a mystery to me. The mask looks to be declared by this call to this piece of

Re: [deal.II] Marking Boundary Nodes in Triangulation

Hi Chen, Is the DoFTools::extract_boundary_dofs() function perhaps what you’re looking for? Best, Jean-Paul > On 23. Jun 2021, at 10:08, Chen R wrote: > > Hi all, > > So I am trying to

Re: [deal.II] Different get_function_gradients

Hi Michael, > Does the (1) do all the work that the last two do? I.e., (1) gives the whole > chunk of gradient, and the last two extract the scalar and vector parts from > the chunk, respectively. > They are very closely related. (1) has no knowledge on the nature of the field(s) for which the

Re: [deal.II] Questions on Step-18

Hi Michael, I cannot comment on the first question, but might be able to assist a bit with the second. But may I first ask, what precisely are you trying to achieve with this extension? As interesting as it is, in the past I had found step-18 to deviate too significantly from the “classical”

Re: [deal.II] Question about deal.II flexibility

Dear Abdelrahman, To add to some further details to what Konrad has already provided: - the step-44 tutorial implements one of many incompressible elasticity formulations. There is also the Quasi-Static Finite-Strain

Re: [deal.II] Linear operators - TrilinosWrappers

ver_S, preconditioner_S ); > //(Case I could invert) > > (Please excuse me for the extension of the code, but the solver function > where I have the issue is too short. In the case you consider it necessary, I > could code a shorter one) > > Thank you so much, > >

Re: [deal.II] Linear operators - TrilinosWrappers

op_S_inv = inverse_operator(opa_S, solver_S, preconditioner_S > ); > > I am not sure what is happening because all the operators are declared as > "LA::MPI::Vector". > If you have any suggestion, would be greatly appreciated. > > Thank you so much, > >

Re: [deal.II] Linear operators - TrilinosWrappers

Hi again Feilpe, Regarding the lack of documentation, I’ve opened an issue on Github to track this. You can find that here: https://github.com/dealii/dealii/issues/12466 <https://github.com/dealii/dealii/issues/12466> Best, Jean-Paul > On 15. Jun 2021, at 12:57, Jean-Paul Pelter

Re: [deal.II] Linear operators - TrilinosWrappers

Hi Feilpe, Firstly, I agree that the documentation is very light on details on how to use the linear operators with Trilinos linear algebra types. We can definitely improve this, and any contributions to that effect would be greatly appreciated! Right now, I can direct you to a few of the

Re: [deal.II] Problem Running Step-1

Hi Kavya, The 9.2 Mac package was built before these new Apple M1 chips were released, so it is unfortunately not compatible with them. I’ve got no experience with it, but you could try to use the Apple Rosetta application to see if that can somehow work around the issue. Here’s a link that

Re: [deal.II] Deal.II Make error || Make release

It > resulted in a similar error with another new error. Please have a look at the > following .txt file to know more about it. I'm not sure what's going wrong > every time. > > Thanks in advance, > > On Saturday, June 12, 2021 at 2:15:28 AM UTC-5 Jean-Paul Pe

Re: [deal.II] Deal.II Make error || Make release

Hi David and Sumanth, There is a new Mac package for the soon to be announced 9.3 release that is built for BigSur. Can you try that, and see if it works for you? If you have any troubles then we’d appreciate the feedback.

Re: [deal.II] time dependent navier stokes (gallery) does not work

Hi Giang, > Does anyone know which version of deal.II that this example run perfectly? To answer your immediate question: It looks like the last major change to the code happened in Apr/May 2018 which, in conjunction with the version of deal.II that it previously used to target in the

Re: [deal.II] Looping over cells and faces: MeshWorker vs WorkStream

e upcoming release). Best, Jean-Paul > On 31. May 2021, at 19:57, Jean-Paul Pelteret wrote: > > Hi Praveen, > >> Is it possible to use WorkStream to loop over faces ? > > It is, in the sense that you can use it to multithread the loop over all > cells, and th

Re: [deal.II] Re-using outputdata from a previous analysis into a new one

Hi, That’s quite an interesting coupled problem that you’re solving! If I understand correctly, you’re wanting your one problem to solve to completion, and you then want to save that state and load it in another, new simulation? If that’s the case then we have save/load functionality built

Re: [deal.II] Looping over cells and faces: MeshWorker vs WorkStream

Hi Praveen, > Is it possible to use WorkStream to loop over faces ? It is, in the sense that you can use it to multithread the loop over all cells, and then loop over all all faces on a cell yourself. This has been automated in the mesh_loop()

Re: [deal.II] Integrated material and spatial traction forces on boundary not equal

Hi Alex, Yes, at first glance it does look to me like the integration is a problem. You are using the same FEFaceValues object to perform the integration in both the material and spatial configurations, and this is not quite correct with the way that you have things set up. The following

Re: [deal.II] Inhomogeneous periodic boundary constraints

Hi Alex, I’m sorry that I didn’t find the time to contribute any further to our discussion. But I’m really glad to hear that you carried on experimenting and ultimately found a solution to the problem that you were facing. Thank you for sharing the solution with us. When I next have some time,

Re: [deal.II] LineMinimization and p-Laplace

tps://www.dealii.org/current/doxygen/deal.II/namespaceLineMinimization.html#a0c96260fdb08c83fd9c7d84007e0e937> > and adjusted it to my problem. I'm currently reviewing the part where f and > g are build. A full deallog is attached as well. > > Thank you so much for the help, it

Re: [deal.II] Calculating normal vectors to deformed surface with pushforward operation

Hi Alex, Well, the one thing that I can clearly identify as being problematic is that the normal vector does not transform with the deformation gradient (directly), but rather with its cofactor. This is what Nanson’s formula for the transformation of surface areas tell us. We actually have a

Re: [deal.II] dealii does not work on mac OS Big Sur

Hi Farid, Would you care to share more details about what the exact problem is? Are you trying to use the MacOS package, or building from source? If the latter then a full build log would be very useful. I’m not sure if any of the developers has a Mac that runs Big Sur (or if our CI testers

Re: [deal.II] GridTools::find_cells_adjacent_to_vertex: how to avoid multiple calling ?

Hi Simon, You could call GridTools:: find_cells_adjacent_to_vertex() with the triangulation instead of a DoFHandler, and then just convert the returned iterators to the type used by each DoFHandler using the method outlined here:

Re: [deal.II] integrating over boundaries

Hi Sylvain, Thanks for detailing your attempts so thoroughly. With this > // I recover the value of conductivity > MaterialData material_data; > const typename DoFHandler::cell_iterator current_cell = > input_data.template get_cell>(); > FullMatrix conductivity = >

Re: [deal.II] interpolate FE_Nelelec

n > complicated meshes. In 3D the lowest order is fine. NedelecSZ (for 2D lowest > order and 3D all orders), as Jean-Paul pointed out, are another option. They > are meant to by-pass certain mesh orientation issues on complicated > geometries (I can tell you a bit about that since currentl

Re: [deal.II] Removing cells in parallel distributed triangulation

Hi Reza, With no context as to how element deletion affects the geometry itself, may I ask if you’ve considered element deactivation using the FE_Nothing element? If you can afford to store the mesh but primarily want to ensure that no DoFs are assigned to a region outside of the physical

Re: [deal.II] LineMinimization and p-Laplace

formation: > Incorrect bounds > > The last few LS iterations do look strange, they barely changed. > > When run with more dofs on the same mesh (16 cells, 81 dofs) I get > convergence failure. There is a regularization parameter epsilon=1e-5, with > larger epsilon on

Re: [deal.II] interpolate FE_Nelelec

Hi John, Unfortunately, you’ve fallen into the trap of confusing what the entries in the solution vector mean for the different element types. For Nedelec elements, they really are coefficients of a polynomial function, so you can’t simply set each coefficient to 1 to visualise the shape

Re: [deal.II] LineMinimization and p-Laplace

Hi Julie, So as you know from the error message, the assertion on this line is being triggered. The fit function is called from this section of code

Re: [deal.II] interpolate FE_Nelelec

To add to Wolfgang’s comment, you can have a look at the compute_edge_projection_l2() function that forms a part of the function that computes

Re: [deal.II] dealii/spack on apple m1

Dear Praveen, Even though you’re trying to install deal.II, it would seem that the issue that you documented sysctl: unknown oid 'machdep.cpu.leaf7_features' sysctl: unknown oid 'machdep.cpu.vendor' sysctl: unknown oid 'machdep.cpu.model' sysctl: unknown oid 'machdep.cpu.leaf7_features' sysctl:

Re: [deal.II] interpolate FE_Nelelec

Dear John, I’m not sure that there is an interpolation function that would work in that way for Nedelec elements (there is VectorTools::project_boundary_values_curl_conforming_l2() for

Re: [deal.II] Mesh Refinement & Periodic B.C.

Hi Stephen, I know that Wolfgang has already answered you and has mentioned that having the refinement levels differ across periodic interfaces is permitted. At some point I wanted to ensure that they were identical, and I wrote a little function to do that and have pasted it below just in

Re: [deal.II] Creating a FESystem with bulk and surface FE spaces

Thanks for your suggestion. I think this is a very nice approach, > > Manuel > > > On Monday, March 29, 2021 at 8:09:39 PM UTC+3 Jean-Paul Pelteret wrote: > Hi Manuel, > > As a small addition to what Wolfgang has already suggested, you can also > consideri

Re: [deal.II] Doubt in collect_periodic_faces() documentation

Hi Vachan, To supplement the link that Wolfgang shared, there’s also a detailed step-by-step guide for contributing patches to the library that can be found on our Wiki page: https://github.com/dealii/dealii/wiki/Contributing Looking

Re: [deal.II] Creating a FESystem with bulk and surface FE spaces

Hi Manuel, As a small addition to what Wolfgang has already suggested, you can also considering using the hp framwwork in conjunction with FE_Nothing elements in order to, effectively, disable elements in the interior of the

Re: [deal.II] The periodic boundary condition for an RVE analysis

Hi Farzin, To complement what Daniel already said, I noted in this previous post an approach whereby you solve for the microscopic fluctuation field directly (i.e. using homogeneous periodic constraints) and then correct for the

Re: [deal.II] Remeshing strategy discussion and implementation

Hi Rajat, I’m a bit ashamed to say that I’ve had a pull-request that adds support for Mesquite and Verdict to the library out for quite some time now. That’s this one here: https://github.com/dealii/dealii/pull/8196 That includes all of the CMake

Re: [deal.II] Inhomogeneous periodic boundary constraints

Hi Alex, I can only give you a very brief answer right now: Using the AffineConstraints::set_inhomgeneity() method, you can add the inhomogeneity after constructing the homogeneous

Re: [deal.II] Multiple material IDs

Hi Corbin, To add to Daniel's suggestion, you could also associated some generic data structures to your cell that you could store the multi-material id data in, and query it as you like. I can think of three different ways to do this: 1. Directly attach your data structure to each cell's

Re: [deal.II] Hashing / mapping Point locations to material ID

Hi Corbin, Just add such a hash function for Point. In case you haven't yet done this, I've dug out an old snippet of code that implements a reliable hash function for the point class. I used this approach successfully when implementing some exotic constraints manager, so hopefully it

Re: [deal.II] Transferring data between two triangulations (dof handlers)

Hi Yu, Have you tried the VectorTools::interpolate_to_different_mesh() functions? It sounds to me like they perform the operation that you're trying to do. They require that the two

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

Hi Behrooz, When you install deal.II using Spack, it is completely isolated from the system environment. That way, you can install multiple versions of the same package without them conflicting with one another. Before you can use deal.II though spack, you populate all of the environment

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

<http://m4lab.unibs.it/faculty.html> On Thu, Jan 14, 2021 at 7:57 PM Jean-Paul Pelteret mailto:jppelte...@gmail.com>> wrote: Hi Alberto, I concur with Bruno. ADOL-C changed the location of their project and repository, so Spack's master branch must be directing you to

Re: [deal.II] Re: issue in installing dealii@9.2 on ubuntu through spack

Hi Alberto, I concur with Bruno. ADOL-C changed the location of their project and repository, so Spack's master branch must be directing you towards the old site. Clearly it doesn't have an updated package for deal.II either, because its trying to deduce the location of the deal.II tarball on

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

find the 'spack-build.out' file as attached. This is what Spack mentioned as a build log for details. Hope to be the correct one. Thank you very much, Behrooz On Wed, Jan 13, 2021 at 8:14 PM Jean-Paul Pelteret mailto:jppelte...@gmail.com>> wrote: Hi Behrooz, Great, I'

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

any way around? Thank you very much, Behrooz On Friday, January 8, 2021 at 7:22:45 PM UTC+1 Jean-Paul Pelteret wrote: Dear Behrooz, The problem here is that your Trilinos installation includes the SEACASChaco package. We'd discovered that there's a common global symbol tha

Re: [deal.II] ADOL-C not found through SPACK installation of deal.ii 9.2

Dear Behrooz, The problem here is that your Trilinos installation includes the SEACASChaco package. We'd discovered that there's a common global symbol that both ADOL-C and Trilinos-SEACASChaco emit, which causes some very strange issues when using ADOL-C. Naturally, we had to make sure that

Re: [deal.II] Stabilized FEM implementation with bubble function

Hi Lixing, Another tutorial that might be of interest to you to look at is step-44 . In that tutorial, two discontinuous fields are condensed out in one of two ways (there's a switch to choose which method is applied). The first

  1   2   3   4   5   6   >