Hello Wolfgang, It is ok, you can apply patch yourself.
I actually also had to specialize many template functions to work with the new type (those related to matrices and vectors, BlockMatrixBase::add, SparseMatrix::add and also local_apply_boundary_conditions etc.). There are some functions that do not work well with the user-defined types like Vector<>::allocate(), Vector<>::deallocate() and Vector<adouble>::operator =(). They cause seg. faults. I am not sure why, perhaps because of mem.align you use (Utilities::System::posix_memalign) and it is fine for primitive types. Anyway that is something internal for my case. I am finishing what I started doing and will write you about an interesting application of deal.II. It is mostly useful for multi scale modelling in chemical engineering but is general in nature. It is coupling of deal.II with an equation-based simulator: basically, using deal.II only to assemble matrices/rhs (including non-linear FE cases), generating equations and then solving one or more of these systems together with other differential and algebraic equations in a large DAE system. All that is done from python (although implemented in c++). An example could be Lithium-ion batteries: electrodes are typically made out of a porous material composed of large numbers of solid particles, and particles are in a electrolyte. Particles (transport modelled using the FE method) are coupled at the larger electrode length scale via electrolyte transport (using the finite volume method). Two software are fully coupled and the boundary conditions can be set using the equations from the other software etc. Dragan On Wednesday, September 14, 2016 at 9:41:36 AM UTC+1, Wolfgang Bangerth wrote: > > > Dragan, > > > Here is the patch. I added one more change in functions > Vector<Number>::reinit: > > if (omit_zeroing_entries == false) > > *this = static_cast<Number>(0); > > The line above fails if the Number type is not primitive. If it is a > class it > > can't cast. So it could be: > > if (omit_zeroing_entries == false) > > *this = Number(0); > > Therefore it will call a constructor or simply create a primitive type. > I do > > not know if there are some ramifications of changing that line. > > Please have a look. > > Yes, all of this looks correct. I think the *declaration* of these > explicit > specializations should be moved to the bottom of the .h file, though. > > Do you know how to use github? This would make sure that you get credit > for > the patch, as you should! If you want to learn how to use it, take a look > at > lecture 32.8 here: > http://www.math.colostate.edu/~bangerth/videos.html > If you want me to apply the patch, just say so, and that's ok with me as > well. > > Best > Wolfgang > > -- > ------------------------------------------------------------------------ > Wolfgang Bangerth email: [email protected] > <javascript:> > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
