[deal.II] Re: "operator+=" error in the assemble_system()

Dear Kyusik, Firstly (and just so that we're all clear on what you're trying to implement), was I correct that your comment that I linked contained the description of the integral that you are trying to compute? > As far as I know fe_values2.shape_value(i,q_index) is vector-valued shape > fu

[deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, I had a quick look in the source code to verify that this flag is being passed to the solver (it is). I've not used this option before so I'm afraid I don't have many ideas. The only thing that comes

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

solver) and cast the objects > correctly I get the expected log from Aztec. > > On Tue 30. May 2017 at 07:10, Jean-Paul Pelteret <> wrote: > >> Hi Julian, >> >> I had a quick look in the source code to verify that this flag is being >> passed >>

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, Here's the reference to the issue <https://github.com/dealii/dealii/issues/4443> I've just opened on GitHub. Best, J-P On Tuesday, May 30, 2017 at 7:54:18 AM UTC+2, Jean-Paul Pelteret wrote: > > Hi Julian, > > Well, it seems then that my lack of optimi

Re: [deal.II] Re: Expecting verbose output from AztecOO when using AdditionalData::output_solver_details

Hi Julian, Great! We're looking forward to your contribution :-) Best, J-P On Tuesday, May 30, 2017 at 8:14:55 AM UTC+2, Julian A wrote: > > I'm happy to do so. I will start next week when I'm in the office again. > > Thanks for the suggestions. > > Regards > -- The deal.II project is locate

[deal.II] Re: dealii, installation error with mpi

Dear Jaekwang, A hint to what the problem might be is in the error message. These lines -- HDF5_LIBRARIES: > /usr/lib64/libhdf5_hl.so;/usr/lib64/libhdf5.so;/usr/local/mpi/mvapich2/2.2/intel/17.0/lib/libmpi.so > -- Insufficient hdf5 installation found: hdf5 has to be configured with > the same

[deal.II] Re: component mask and Dirichlet bc application

Dear Alberto, In my opinion both of the approaches that you've outlined are plausible ways of implementing Dirichlet constraints, but there are a couple of key differences that I can quickly outline. I'll refer to the approach listed in your first post as method 1 and the split approach in your

Re: [deal.II] Re: component mask and Dirichlet bc application

Dear Alberto, Thanks for your feedback. We'll take a look at the documentation and try to see how/where it can be enhanced. Best, Jean-Paul On Thursday, June 1, 2017 at 12:51:42 PM UTC+2, Alberto Salvadori wrote: > > Thank you Jean Paul, > very clear. Perhaps your notes could be added on the de

Re: [deal.II] Installation error

Hi Lev, The information that you were looking for is in the CMake related documentation . You need to pass the -DDEAL_II_FORCE_BUNDLED_THREADS=ON option at configuration time. I hope that this helps. Regards, J-P On Tuesday, Ju

[deal.II] Re: slepc installation error - How does one find the CHECKSUM for slepc to put in /candi/deal.II-toolchain/packages/slepc.package ?

Hi Kartik, It looks like candi uses md5 to verify downloads. What you could do is manually download the file off of their website and run "md5 slepc-3.7.4.tar.gz" to compute the checksum yourself. I hope that this helps! Regards, Jea

Re: [deal.II] Re: hp HDG in deal.II

I've updated the Wiki entry to point to the video lecture as well. On Wednesday, June 28, 2017 at 12:08:12 PM UTC+2, Wolfgang Bangerth wrote: > > On 06/26/2017 07:12 AM, sml.imf...@gmail.com wrote: > > > > Thanks for your answer, your approach actually worked quite well. (How > would I > > go

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 case

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 Neuma

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

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 c

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

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 functi

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] 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 domai

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 cur

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 = > mate

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: https://github.com/dealii/dealii/wiki/Frequently-Asked-Questions#c

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 run

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 fu

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

lt;https://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 hel

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] 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 (which

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] 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 into

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] 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 CMakeLis

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. https://github.com/dealii/dealii/releases/download/v9.3.0/dealii-9.3.0-b

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

> 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 Peltere

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 exp

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 tests

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

functions > are not matching. > (const auto 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

Re: [deal.II] Linear operators - TrilinosWrappers

r(op_S, solver_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 m

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 Quasi-incompress

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] 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] 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] 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 m

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: > &g

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 ma

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

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: 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] 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 para

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] 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] 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] 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 mi

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 please

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

that you should install these packages, and then give it another 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. > &

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/fetch.php?

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] 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] 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] 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 co

Re: [deal.II] Matrix Multiplication

; using 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 P

Re: [deal.II] Matrix Multiplication

p;, const std::vector&) [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] '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 prev

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);” somethi

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

cs::Elasticity::Kinematics::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:

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 in

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] point_value, Real&Imaginary 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, solution,Point<2>(

Re: [deal.II] point_value, Real&Imaginary 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] 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 “intersectin

[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] 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 coarsen

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] 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 Skel

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 tens

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 col

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] 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] 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] 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: https://github.com/dealii/dealii/blob/master/tests/lac/l

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 DataPostprocessorInp

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: https://g

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 wha

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] 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 reinit

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 7:50:4

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 not

Re: [deal.II] automatic differentiation:

tangent \frac{\partial S_ad}{\partial > C_ad}. > > All that said, is it not correct to start like this?: > SymmetricTensor<2,dim> C = symmetrize(F^t *F); > ad_helper.register_independent_variable(C, C_dofs); > const SymmetricTensor<2, dim, ADNumberType> C_ad = > ad_helper.ge

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 t

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 de

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: https://dealii.org/developer/doxygen/deal.II/symmetric__tensor_8h.html#aa18a9d623fcd5

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] 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, < c

[deal.II] Re: The violated condition was: (update_flags & update_normal_vectors) == false

Dear Franck, It looks like you're passing the flag "update_normal_vectors" to an FEValues object, which is not sensible as it is used only for volume calculations (as opposed to surface calculations). I think that this is the propogation of the flags that leads to the issue: DarcySys

[deal.II] Re: Adding external library to libdeal_II

Dear Victor, Can you clarify something: Have you modified a copy of deal.II such that your library is now an explicit dependency (i.e. deal.II now has some function calls to your library), or is your library only being referenced through some functions called inside another code (e.g. "step-3"

[deal.II] Re: Adding external library to libdeal_II

unction defined in my library). > > Thank you! > > On Tuesday, July 4, 2017 at 3:47:38 PM UTC+2, Jean-Paul Pelteret wrote: >> >> Dear Victor, >> >> Can you clarify something: Have you modified a copy of deal.II such that >> your library is now an explicit depen

[deal.II] Re: Adding external library to libdeal_II

Hi Victor, Another think that I noted is that the file mysolver.cc that I added under > source/lac is not being compiled and linked to libdeal_II.so (I could not > find it in the link.txt file that I attached). Do I need to do something > else in order to cmake recognize that this file need to

Re: [deal.II] Re: hp HDG in deal.II

Dear Simon, 1. Track deal.II's remote master branch git remote add dealii g...@github.com:dealii/dealii.git 2. Fetch the up-to-date master from the deal.II remote git fetch dealii 3. Merge or rebase as necessary: git merge dealii/master or git rebase master In all likelihood "rebasing" is the b

<    1   2   3   4   5   6   7   8   >