[deal.II] question on video Lecture 27

On page 12, for 1d unit interval problem why dim(A)=1/h? rather than 1/h+1? -- 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 Group

Re: [deal.II] question on video Lecture 27

Thank you! On Monday, December 30, 2019 at 7:14:27 AM UTC-7, Wolfgang Bangerth wrote: > > On 12/30/19 4:23 AM, Alex wrote: > > On page 12, for 1d unit interval problem why dim(A)=1/h? rather than > 1/h+1? > > Fair question -- I should have said >dim(A) = (1/h)+1 \

[deal.II] step-11 boundary element

Hi all I am new to dealii. I have a question on step-11. For a domain with a curved boundary such as step-11 with fe(1), is the boundary element still a bilinear one if mapping order>1? i.e. always 4 dofs on a boundary element? Thanks Alex -- The deal.II project is located at h

Re: [deal.II] step-11 boundary element

Thank you. Do you have any recommendation for reference notes or books which explains the math behind mapping? I can see some in Mapping< dim, spacedim > Class Template Reference. Alex On Thursday, July 9, 2020 at 7:01:34 AM UTC-6, Wolfgang Bangerth wrote: > > On 7/9/20 1:18 AM

Re: [deal.II] Issue with Applying Dirichlet Boundary Conditions

results. Would you have any thoughts on why this might be happening? Any guidance would be greatly appreciated. Regards, Pradeep. On Wednesday, March 19, 2025 at 7:51:37 AM UTC+1 Jean-Paul Pelteret wrote: > Hi Alex, > > I haven't inspected your code in detail, but I would sugg

[deal.II] Issue with Applying Dirichlet Boundary Conditions

Hello everyone, I am modifying the Step-44 (Quasi-Static Finite-Strain Compressible Elasticity) tutorial in deal.II to incorporate thermo-mechanical equations. However, I am facing an issue with applying temperature Dirichlet boundary conditions. Problem Description: I am applying the tempe

Re: [deal.II] Issue with Applying Dirichlet Boundary Conditions

Dear Prof. Wolfgang, Thank you very much for your kind response. I sincerely appreciate your insights. However, I believe this aspect has already been addressed in step-44 through the conditions mentioned below. // Since the constraints are different at different Newton iterations, we //

[deal.II] Issue with Applying Dirichlet Boundary Conditions

Hello everyone, I am modifying the Step-44 (Quasi-Static Finite-Strain Compressible Elasticity) tutorial in deal.II to incorporate thermo-mechanical equations. However, I am facing an issue with applying temperature Dirichlet boundary conditions. Problem Description: I am applying the tempe

Re: [deal.II] Compute the error residual for a specific DOF component

ints.is_constrained(i)) > … > > > > https://www.dealii.org/current/doxygen/deal.II/namespaceDoFTools.html#a45f4d01f1c4c6337e4be6f10a81fbdab > > > Best, > Luca. > > > > On 29 Apr 2025, at 10:08, Alex wrote: > > > > Dear deal.II users, > > I'm work

[deal.II] Compute the error residual for a specific DOF component

compute the residual *only for the displacement component* (or any other specific field). Thanks in advance! Regards, Alex -- 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

Re: [deal.II] Issue with Applying Dirichlet Boundary Conditions

the issue still persists! Thank you in advance for your time and help. On Thursday, March 20, 2025 at 9:51:50 AM UTC+1 Alex wrote: > Dear Prof. Wolfgang, > > Thank you very much for your kind response. > > I sincerely appreciate your insights. However, I believe this aspect has >

Re: [deal.II] Catching exception for find_active_cell_around_point?

ell. Aborting! After digging through the source code and documentation a bit, I was worried that this is the expected behavior of AssertThrow and that I could not suppress the abort signal.

Re: [deal.II] Catching exception for find_active_cell_around_point?

I left out something important: I'm on a 8.5.0-pre version. (I don't see a way to edit my post.) On Wednesday, August 17, 2016 at 12:18:30 PM UTC+2, Alex Zimmerman wrote: > > I'm new to deal.II and I'm having a similar problem. I'm trying to extend >

Re: [deal.II] Catching exception for find_active_cell_around_point?

hread if I make progress :) On Wednesday, August 17, 2016 at 12:18:30 PM UTC+2, Alex Zimmerman wrote: > > I'm new to deal.II and I'm having a similar problem. I'm trying to extend > the FEFieldFunction class with an extrapolated_value method that handles > this exce

Re: [deal.II] Catching exception for find_active_cell_around_point?

UTC+2, Alex Zimmerman wrote: > > I just stepped through my program with qtcreator and I found a mistake > that undermines my question. I thought I was using this extrapolated_value > method, but I was still using the parent class's value method. I imagine > that this will wor

[deal.II] Re: Failing to set up simple test configuration

/1 Test #1: tests/my_test.debug .. Passed5.51 sec > 100% tests passed, 0 tests failed out of 1 > Total Test time (real) = 5.52 sec One of these days I'll ask a question that I don't answer myself a few minutes later :) On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex

[deal.II] Re: Failing to set up simple test configuration

Actually numdiff was already installed; I think that error was referring to the file simply not existing. See my latest reply. Thanks for your time! On Wednesday, September 7, 2016 at 10:05:38 AM UTC+2, Jean-Paul Pelteret wrote: > > Hi Alex, > > numdiff: output: No such file

[deal.II] Re: Failing to set up simple test configuration

, September 7, 2016 at 10:07:06 AM UTC+2, Alex Zimmerman wrote: > > This might be a problem with my file system. I've been successfully using > the Ubuntu subsystem on Windows 10 for the past few weeks, and that's where > the odd "/mnt/c/Users..." path comes fr

[deal.II] Re: Failing to set up simple test configuration

n on GitHub > <https://github.com/dealii/dealii/issues/3060> related to running deal.II > on windows. Its interesting to hear that you've got it running on Windows > 10. Out of curiosity, how have you configured deal.II? Do you link it > against any external libraries? > >

Re: [deal.II] Re: Failing to set up simple test configuration

an run ctest on the Windows filesystem (from the bash prompt). On Wednesday, September 7, 2016 at 10:36:21 PM UTC+2, Wolfgang Bangerth wrote: > > On 09/07/2016 06:56 AM, Alex Zimmerman wrote: > > > > After some brief Googling, I think I might even be able to fix this > issue

Re: [deal.II] Re: Failing to set up simple test configuration

o Heister wrote: > > Hey Alex, > > I am not surprised you are running into issues, because you are the > first one to try "ubuntu on windows" to compile deal.II with (at least > as far as I know). > > It could be a permission problem that you are running into,

[deal.II] Untraceable "not implemented" error in GDB

A couple of times now I have encountered GDB output similar to my attached snapshot. The previous time I had only made a very small change to my code, so it was easy enough for me to figure out on my own. Presently I'm trying to run a 1D version of my code for the first time. So far I've only r

[deal.II] Re: Untraceable "not implemented" error in GDB

Yep that does it! Thanks for your patience :) On Friday, September 16, 2016 at 7:28:41 PM UTC+2, Bruno Turcksin wrote: > > Alex, > > before the run command, you need to use: catch throw > > Best, > > Bruno > > On Friday, September 16, 2016 at 1:21:41 PM UTC-4,

[deal.II] Why is this asserted to be impossible?

I have a code that is an extension of step-26 with non-homogeneous Neumann boundary conditions and zero forcing function, among other changes. Until recently I had only actually run the code in 2D, though I have been continuing the "dimension independent" programming. Yesterday I tried running

Re: [deal.II] Why is this asserted to be impossible?

Bangerth wrote: > > On 09/17/2016 05:20 AM, Alex Zimmerman wrote: > > > > Not understanding why this is impossible, I began digging through the > code a > > bit and thought I would write my own 1D implementation. I noticed that > the > > code in the existing te

[deal.II] How can I resize a std::vector::ParsedFunction>?

al.II/base/thread_local_storage.h:23, from /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/base/logstream.h:23, from /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/lac/vector.h:21, from /mnt/c/Users/Alex/UbuntuShared/nsb-pcm/tests/peclet_data.cc:1: /usr

[deal.II] Re: How can I resize a std::vector::ParsedFunction>?

Correction: Of course I mean a std::vector>. My question title has a in the wrong place. On Wednesday, March 22, 2017 at 4:31:24 PM UTC+1, Alex Zimmerman wrote: > > Fundamentally I am trying to allow for a variable number of ParsedFunction > objects to be specified in a paramete

Re: [deal.II] How can I resize a std::vector::ParsedFunction>?

0; f < function_count; ++f) { prm.enter_subsection("parsed_function_"+std::to_string(f)); { function_pointers[f]->parse_parameters(prm); } prm.leave_subsection(); } return 0; } Thanks, Alex On Wednesday, March 22, 2017 at 4:45

Re: [deal.II] How can I resize a std::vector::ParsedFunction>?

Also for the record, I verified that the test passes if I use a std::vector> without resizing: https://github.com/alexanderzimmerman/nsb-pcm/blob/bugs/tests/bug_10_pass.cc On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman wrote: > > Luca, > > Thanks for the idea.

Re: [deal.II] How can I resize a std::vector::ParsedFunction>?

> assigning them. > > Think of this example: > std::vector v; > v.resize(4); > now v[0] is a pointer to an int, but it is NULL unless you do something > like > v[0] = new int; > > > > On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman > > wrote: &

Re: [deal.II] How can I resize a std::vector::ParsedFunction>?

ue(point, value); std::cout << "f(" << point << ") = " << value << std::endl; } return 0; } On Thursday, March 23, 2017 at 3:05:53 PM UTC+1, Alex Zimmerman wrote: > > Timo, thanks for the extra clarification. As I mentioned

[deal.II] Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

tly, and I'm guessing that this is something quite obvious to most users. Also it would help if someone could point me toward an existing tutorial/example that accesses components of the gradient of a physical vector. I had no luck finding one. Thanks, Alex -- The deal.II project is

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

Thanks for the help! P.S. What's the best way to communicate math equations on the mailing list? I'm just typing what I think is roughly the correct LaTeX syntax, but this seems a bit clunky. On Wednesday, April 5, 2017 at 3:04:04 PM UTC+2, Jean-Paul Pelteret wrote: > > Dear Alex, &

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

.html>. This didn't show up when I was glancing through the tutorials recently. I'm going to see if that tutorial helps :) On Wednesday, April 5, 2017 at 8:14:36 PM UTC+2, Jean-Paul Pelteret wrote: > > Hi Alex, >>> >> > >> Thanks for the clarification, Jean-

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

v is still open, but you saved me from using that ugly loop. Thanks! On Thursday, April 6, 2017 at 10:33:46 AM UTC+2, Alex Zimmerman wrote: > > Thanks for following up. > > I don't think that > double sum = v*gradz*w > > is equivalent to > double sum = 0

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

wrote down the equivalence here: <https://lh3.googleusercontent.com/-BfOP_i7Vx_s/WOYKfP1BodI/UE0/0_3yExW3mGAvbRKhOElaF5rTccfwkHcwgCLcB/s1600/NonlinearNS_TensorContraction.PNG> On Thursday, April 6, 2017 at 10:41:07 AM UTC+2, Alex Zimmerman wrote: > > Correction! When I teste

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

Yes I began this project by reviewing step-8 and the Handling vector valued problems

Re: [deal.II] Inhomogeneous periodic boundary constraints

wable file types. Best, Alex -- 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 u

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

, Alex On Tuesday, May 4, 2021 at 6:58:33 p.m. UTC+2 Jean-Paul Pelteret wrote: > 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 cofacto

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

_u + grad_u_T + grad_u_T * grad_u)}; ADNumberType t1 = lambda / 2 * std::pow(trace(green_lagrange_strain_tensor), 2); ADNumberType t2 = mu * double_contract<0, 0, 1, 1>( green_lagrange_strain_tensor,

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

orce magnitude of ~0.15). However, it does not seem the issue is related to deal.ii, so I will have to consider that further myself. Thanks so much for your help, Best, Alex On Tuesday, May 11, 2021 at 10:54:31 p.m. UTC+2 Jean-Paul Pelteret wrote: > Hi Alex, > > Yes, at first gl

[deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

To be clear, I ran cmake .. -DDEAL_II_CXX_VERSION_FLAG=c++11 The version of cmake is 3.11.4. Any thoughts would be greatly appreciated. Alex -- 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 thi

[deal.II] Re: Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

rforming Test DEAL_II_HAVE_CXX11_ICCNUMERICLIMITSBUG_OK - Success -- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK -- Performing Test DEAL_II_HAVE_CXX11_ICCLIBSTDCPP47CXX11BUG_OK - Success CMake Error at cmake/checks/check_01_cxx_features.cmake:472 (MESSAGE): Alex On Friday, May 21, 2021 at 7:35:16 p.m.

Re: [deal.II] Re: Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

Hi Bruno, It turns out that it was unable to find the header files, as once I set CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH, it was able to pass the tests. Thanks for your help, Alex On Friday, May 21, 2021 at 7:54:47 p.m. UTC+2 bruno.t...@gmail.com wrote: > Alex, > > I think tha

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

und. Best, Alex On Monday, May 24, 2021 at 5:22:57 p.m. UTC+2 Wolfgang Bangerth wrote: > On 5/21/21 11:03 AM, Alex Cumberworth wrote: > > > > I don't really see how this can be, as this version of the compiler > fully > > supports C++11. I also tried setting th

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

a.m. UTC+2 Wolfgang Bangerth wrote: > On 5/26/21 11:17 AM, Alex Cumberworth wrote: > > It seems that the issues stem from not setting the include directories > > properly. Even with CPATH, C_INCLUDE_PATH, and CPLUS_INCLUDE_PATH set as > I > > mentioned in my previous respo

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

_FILE(SACADO_TRAD_HPP Sacado_trad.hpp HINTS /include NO_DEFAULT_PATH NO_CMAKE_ENVIRONMENT_PATH NO_CMAKE_PATH NO_SYSTEM_ENVIRONMENT_PATH NO_CMAKE_SYSTEM_PATH NO_CMAKE_FIND_ROOT_PATH) -- DEAL_II_WITH_TRILINOS successfully set up with external dependencies. Best, Alex On Thursday, May 27, 2021 at 3:21:1

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

;/opt/ohpc/pub/libs/gnu9/openmpi4/hdf5/1.10.6/include;/usr/include;/opt/ohpc/pub/libs/gnu9/openmpi4/boost/1.73.0/include There are further issues past this point, but perhaps if I understand the problem here that will help with the later issues. Best, Alex On Tuesday, June 1, 2021 at 9:02:12 p.m

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

/CMakeFiles/obj_numerics_debug.dir/data_out.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:3317: source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2 make: *** [Makefile:149: all] Error 2 The same error occurs when I use version 13 of Trilinos. Best, Alex On Thursday, June 3, 2021 at

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

urce/numerics/CMakeFiles/obj_numerics_debug.dir/build.make:303: source/numerics/CMakeFiles/obj_numerics_debug.dir/data_out_dof_data.cc.o] Error 1 make[1]: *** [CMakeFiles/Makefile2:3317: source/numerics/CMakeFiles/obj_numerics_debug.dir/all] Error 2 make: *** [Makefile:149: all] Error 2 Best, Alex

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

Best, Alex On Monday, June 7, 2021 at 3:37:11 p.m. UTC+2 d.arnd...@gmail.com wrote: > Alex, > > it looks like Trilinos and SUNDIALS are using different MPI > implementations that are incompatible. There is not much we can do about > this within deal.II. > Can you try to reinsta

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

still compiling, I have passed all previous points where I had errors. Best, Alex On Monday, June 7, 2021 at 5:41:24 p.m. UTC+2 Wolfgang Bangerth wrote: > On 6/7/21 8:41 AM, Alex Cumberworth wrote: > > I noticed that I attached the error file for 9.2, and that the source of > the

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

sure why it seems to only look for the static version of the library. Best, Alex On Monday, June 7, 2021 at 6:11:52 p.m. UTC+2 Wolfgang Bangerth wrote: > On 6/7/21 10:02 AM, Alex Cumberworth wrote: > > The cause of this particular issue actually appears to be some symlinks > to the

Re: [deal.II] Compiling deal.II with GCC version 9.3.0 results in missing C++11 features error

e trilinos and deal.ii without MPI? It seemed here that there are wrapper classes that trilinos will only compile if MPI is enabled? If this is true, perhaps that should be included on this this page <https://www.dealii.org/9.1.1/external-libs/trilinos.html>? Thanks to everyone that helped! B

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

the same level of agreement with beam theory with one order of magnitude fewer degrees of freedom. I guess I am still mildly surprised how refined I had to made the x direction, but perhaps if I also used adaptive refinement things would further improve. Best, Alex On Thursday, June 10, 2021 at 6

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

Hi Wolfgang, I tried a quadratic element, and was able to reduce the number of degrees of freedom for the same level of convergence by another order of magnitude. Thanks! Best, Alex On Friday, June 11, 2021 at 3:34:08 p.m. UTC+2 Wolfgang Bangerth wrote: > On 6/11/21 4:04 AM, Alex Cumberwo

[deal.II] Re: Deal.II site appears to be down

I am also unable to access the website, although it is specifically the documentation pages that are down. Best, Alex On Monday, June 14, 2021 at 2:16:08 a.m. UTC+2 corbin@gmail.com wrote: > Hello everyone, > > It seems dealii.org is experiencing some problems or is down (I

[deal.II] Integrating with curved manifolds

d beam, but with a different second moment of area, and this was in agreements with the FEM calculations with the rectangular cuboid beam. I am using quadratic elements. Any thoughts would be greatly appreciated, Alex -- The deal.II project is located at http://www.dealii.org/ For mailing list

[deal.II] Subdivided cylinder and boundary ids

boundary ids to 0. Best, Alex -- 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] Re: Subdivided cylinder and boundary ids

Hi Bruno, Sure, I can try making a PR this week. Best, Alex On Sunday, June 27, 2021 at 9:36:50 p.m. UTC+2 blais...@gmail.com wrote: > I most likely copied this mistake from the regular Cylinder and did not > think of it when I coded the subdivided cylinder. > Alex, if you feel co

[deal.II] 3D Mixed Simplex Mesh

ems to arrive when I call dof_handler.distribute_dofs(fe); I've attached my modified version of the example program along with my simple mixed-element 3D mesh. Is there something that I am missing regarding the dof_handler when trying to use a 3D mixed-element mesh? Thanks very much,

[deal.II] Re: 3D Mixed Simplex Mesh

I realized that the mesh file I provided had an issue. The corner nodes of the tetrahedral elements coincided with a mid-face node of the hexahedron element. I've fixed that and uploaded a new mesh. Thanks, Alex On Monday, November 7, 2022 at 3:25:25 PM UTC-5 Alex Quinlan wrote: &g

Re: [deal.II] 3D Mixed Simplex Mesh

our advice on writing the steps to write a patch would be most welcome! I will re-review the relevant code and see if I can put together a general plan on how to approach this. Best regards, Alex On Wednesday, November 9, 2022 at 4:44:25 PM UTC-5 Wolfgang Bangerth wrote: > Alex: > > &

[deal.II] Importing nodal BCs and accessing vertices

I'm interested on your thoughts on how to efficiently import nodal boundary conditions from an external file. I couldn't find any other posts on this specific topic, but I apologize if this is a duplicate. Thanks, Alex --

Re: [deal.II] Importing nodal BCs and accessing vertices

Thanks Wolfgang. I appreciate the feedback. I'll see if I can implement some of the cost-saving tips that you suggested. -- 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 mess

[deal.II] Non-polynomial Shape Functions

. Any thoughts on how feasible this would be to implement? Thanks for your input, Alex -- 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

Re: [deal.II] Non-polynomial Shape Functions

Thanks, Wolfgang. I'll dig into FE_Enriched! On Thursday, June 8, 2023 at 6:57:44 PM UTC-4 Wolfgang Bangerth wrote: > On 6/8/23 09:40, Alex Quinlan wrote: > > > > I am looking to modify the FE_Q element to have non-polynomial shape > > functions. It looks like FE_Q

Re: [deal.II] Non-polynomial Shape Functions

~~ It seems that I'm misunderstanding a few things about how FE_Enriched works. Can you see what I'm doing wrong in constructing the FE_Enriched? It looks like there's issues with forms I am using for FE_Q and the enrichment function. Do you have any tips or suggeste

Re: [deal.II] Non-polynomial Shape Functions

_Q(1), &potential ) , 3) Are either of these directions valid? I can't tell if I'm failing to use the correct syntax or if I'm completely off base with the approach. Thanks, Alex -- The deal.II project is located at http://www.dealii.org/ For mailing

Re: [deal.II] Non-polynomial Shape Functions

; const FESystem fesys; Cheers, Alex On Wednesday, June 21, 2023 at 1:25:44 AM UTC-4 Wolfgang Bangerth wrote: > On 6/20/23 10:00, Alex Quinlan wrote: > > > > How can I go about getting a vector solution with FE_Enriched? I have > tried > > to use vector arguments

Re: [deal.II] Copy blocks of BlockSparseMatrix

E F H I ] Timo, I have tried the solutions that you suggest, but none of them work, I keep getting a segmentation fault error. Could you please give me an alternative option? Thank you so much. Regards, Alex On Wednesday, April 29, 2015 at 9:28:59 AM UTC-6, Timo Heister wrote: > > H

Re: [deal.II] Copy blocks of BlockSparseMatrix

of the blocks of matrix m22 is not working properly.. Thanks for your help. Cheers, Alex On Monday, October 16, 2017 at 9:03:05 AM UTC-6, Daniel Arndt wrote: > > Alex, > > Hi all, >> >> I am having a similar problem. I want to take a 3x3 BlockSparseMatrix m33 &

Re: [deal.II] Step-22 with more than 20 million DOFs

Hi Wolfgang, thank you for your reply. I will look at the extensions of step-22, as well as the parallelization of the code detailed in step-32. Cheers, Alex El divendres, 26 juny de 2020 10:24:20 UTC-6, Wolfgang Bangerth va escriure: > > > Alex, > > > I am solving the S

[deal.II] Velocity laplacians

3. Filled the object using the "get_function_laplacians" function in deal.ii. However, I am getting "-nan" in some of the cells, and I am not sure that my procedure is correct. Could you please tell me what am I missing? Thank you! Alex -- The deal.II project is located at htt

Re: [deal.II] Re: Interacting with Python data // external codes

tension module. In my experience, the trickiest part of this is not Cython per se, but getting testing and continuous integration working with the mix of languages: C++, Cython, Python, and your build system (CMake?) mini-language. If you choose this route, another option for controlling y

Re: [deal.II] Re: Interacting with Python data // external codes

ossible >as in 1)? > > I think the best way to do this would be with the Cython approach > suggested by Alex, however, it's unclear to me the best way to pass the > cell-based data to Python. Is it possible to define a struct on from > deal.ii containing the data in

Re: [deal.II] Tie constraints in deall.II?

Thanks for the information. Unfortunately I am more interested in the second case, so I will look around for examples of the mortar element/master slave approach. Alex On Thursday, December 17, 2020 at 2:11:14 a.m. UTC+1 Wolfgang Bangerth wrote: > > > I am considering switching t

[deal.II] Inhomogeneous periodic boundary constraints

together some of the faces (e.g. to form a ring -- I included an image of this in a previous post <https://groups.google.com/g/dealii/c/kkYfnir8QVQ/m/Q6G30LFuCAAJ>). Any thoughts would be greatly appreciated. Best, Alex -- The deal.II project is located at http://www.dealii.org/ For

Re: [deal.II] Inhomogeneous periodic boundary constraints

correct. Any further thoughts would be much appreciated. Best, Alex -- 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 "d

[deal.II] Mixed codimensionality

days, weeks, months) I realize that there are alternative methods to represent the physical system that could avoid this problem. However, I am essentially being asked to automate the conversion from existing abaqus input files into deal.ii. I appreciate any ideas you all might have. Than

Re: [deal.II] Mixed codimensionality

dof_indices across 3 dof_handlers so they can be added to the correct place in the system_matrix 2) Connecting the triangulations within the system matrix. Have I understood your suggestion correctly? Do you forsee any other challenges? Thanks very much, Alex -- The deal.II project is located at http

Re: [deal.II] Mixed codimensionality

g/current/doxygen/deal.II/group__constraints.html#gaf10030e7a598def1a1fa43fb0c005a93>(dof_handler, dsp); I'm unable to use this line because I have the two separate DOF handlers. Do you have any idea of what I can do here? Best regards, Alex On Saturday, October 28, 2023 at 6:58:21 PM U

Re: [deal.II] Mixed codimensionality

Dear Luca and Wolfgang, Thanks for your pointers; I will work to implement them. My github account is: https://github.com/AlexQuinlan Thanks, Alex On Wednesday, November 8, 2023 at 3:36:43 AM UTC-5 luca@gmail.com wrote: > Dear Alex, > > if you send me your github user, I’ll

Re: [deal.II] Mixed codimensionality

A piece of code is attempting a division by zero. This is likely going to lead to results that make no sense. I'm guessing this is related to the inverse operators? So, I'm curious if there's some way to use this approach for problems that have a Schur complements that

Re: [deal.II] Mixed codimensionality

Sorry, please disregard my last question. I've reviewed the Step-20 solver that I tried to use and I see that it is a different set-up to my problem. I'm now working to apply the Schur complement in the correct manner. On Wednesday, November 8, 2023 at 10:32:35 AM UTC-5 Alex Qui

Re: [deal.II] Importing nodal BCs and accessing vertices

he size of the mesh and the number of constraints to be added. I have not done any speed testing on this yet, tho. Do you think it would be looking into? Or do you see some fatal flaw with this approach? Thanks, Alex On Wednesday, January 18, 2023 at 8:31:11 AM UTC-5 Alex Quinlan wrote: > Th

Re: [deal.II] Importing nodal BCs and accessing vertices

Thanks, Wolfgang. I will abide by those guidelines. On Tuesday, November 14, 2023 at 10:15:29 PM UTC-5 Wolfgang Bangerth wrote: > On 11/14/23 16:25, Alex Quinlan wrote: > > > > I'm curious what your thoughts are on this approach. I imagine it could > have > > an

[deal.II] Should DEAL_II_LIBRARIES be available via deal.IIConfig.cmake?

al.II/changes_between_9_4_0_and_9_5_0.html Is retaining these variables a possibility? Or is there some reason the use of these variables (DEAL_II_INCLUDE_DIRS, DEAL_II_LIBRARIES_DEBUG, ...) should be discontinued by users, in favor of some alternative...? Thanks and regards Alex -- The de

[deal.II] Reporting issue with repo

very savvy with git, so I thought I would just post here. Is this the correct place to make this kind of report, or is there a preferred process that I should take in the future? Thanks, Alex -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see

Re: [deal.II] Artificial cells on large imported meshes during parallel::distributed

allel::fullydistributed, so I will start here: https://github.com/peterrum/dealii-pft Best regards, Alex On Wednesday, December 13, 2023 at 11:27:41 AM UTC-5 d.arnd...@gmail.com wrote: > Alex, > > in this case, the triangulation is copied for all processes when using > para

[deal.II] Imported mesh problem with p4est and parallel::distributed

y related issue: - What is needed to allow for simplex meshes with parallel::distributed? Is this also a connectivity issue? Many thanks, Alex -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/deali

Re: [deal.II] Imported mesh problem with p4est and parallel::distributed

/tests/fullydistributed_grids/copy_serial_tria_*, starting with parallel:shared:triangulation and then building the p:f:t off of that. This allows me to side-step bug-7428 and to import a simplex mesh. Best regards, Alex On Tuesday, December 19, 2023 at 8:26:04 PM UTC-5 Wolfgang Bangerth wrote

Re: [deal.II] Mixed codimensionality

his problem? The suite of GridTools::partition_triangulation seem like they will not work for my two-triangulation approach. Best regards, Alex On Thursday, November 9, 2023 at 1:24:29 PM UTC-5 Alex Quinlan wrote: > Sorry, please disregard my last question. I've reviewed the Step-20 solv

Re: [deal.II] Mixed codimensionality

ve an issue with the off-diagonal matrices and the coupling between the two triangulations. Is it possible for me to build up all of the sparsity patterns and matrices *and then *perform the partitioning? Thanks, Alex On Tuesday, January 16, 2024 at 10:04:52 PM UTC-5 Wolfgang Bangerth wrot

Re: [deal.II] Mixed codimensionality

ent? Is it all of the locally owned/relevant dofs? Do I just combine the vector of locally owned shell dofs and locally owned solid dofs? Thanks, Alex On Wednesday, January 17, 2024 at 8:24:44 PM UTC-5 Wolfgang Bangerth wrote: > On 1/17/24 14:40, Alex Quinlan wrote: > > > > I

Re: [deal.II] Mixed codimensionality

Thanks, Wolfgang. I seem to have it working now, though I've hit some other unrelated snags that I need to resolve. Once I get those fixed and confirm that my program is running correctly, I would be willing to work on a patch. Thanks, Alex On Friday, January 19, 2024 at 1:00:51 PM

Re: [deal.II] Imported mesh problem with p4est and parallel::distributed

AMG preconditioner? I have limited understanding of solvers and preconditioners, so I am trying to learn more about them. I'd appreciate any input you may have. Best regards, Alex On Friday, December 22, 2023 at 10:13:55 AM UTC-5 Alex Quinlan wrote: > Thanks for your response, Wolfgang. >

Re: [deal.II] Imported mesh problem with p4est and parallel::distributed

Thanks, Wolfgang. I'll look into it some more and eventually try with a larger problem. On Tuesday, January 30, 2024 at 11:18:01 PM UTC-5 Wolfgang Bangerth wrote: > > Alex: > > > I am running a solid-mechanics job where I import a large mesh and run > using > > p

Re: [deal.II] Mixed codimensionality

sembly. I've looked at Step-55 and Step-70, which use the MPI::BlockSparseMatrix, but I don't see what I'm missing. These examples use an index set locally_relevant_dofs_per_processor, but I am using a vector of index sets, since I have two DoF handlers. Can anyone see where I m

Re: [deal.II] Mixed codimensionality

does indeed have (48,36). Any thoughts on where I might be causing this problem? Best regards, Alex On Thursday, February 1, 2024 at 7:56:05 PM UTC-5 Wolfgang Bangerth wrote: > On 2/1/24 14:50, Alex Quinlan wrote: > > > > Can anyone see where I may have gone wrong or what I ha

  1   2   >