Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
I found a fix for this by editing the deal.ii source code. I am very new to
deal.ii so it is extremely likely that there is a way to accomplish what I
want without touching the deal.ii source or there might be a better way of
editing the source. So, here is the fix that worked for me. Let me know if
there is a better solution.
I first implemented a new reinit function for IntegrationInfo:
/**
* Reinitialize internal data structures for use on a cell.
*/
template
void
reinit(ITERATOR cell, const DoFInfo );
template
template
inline void
IntegrationInfo::reinit(ITERATOR cell,
const DoFInfo )
{
for (unsigned int i = 0; i < fevalv.size(); ++i)
{
FEValuesBase = *fevalv[i];
if (info.sub_number != numbers::invalid_unsigned_int)
{
// This is a subface
FESubfaceValues =
dynamic_cast &>(febase);
fe.reinit(cell, info.face_number, info.sub_number);
}
else if (info.face_number != numbers::invalid_unsigned_int)
{
// This is a face
FEFaceValues =
dynamic_cast &>(febase);
fe.reinit(cell, info.face_number);
}
else
{
// This is a cell
FEValues =
dynamic_cast &>(febase);
fe.reinit(cell);
}
}
const bool split_fevalues = info.block_info != nullptr;
if (!global_data->empty())
fill_local_data(info, split_fevalues);
}
And then I changed the MeshWorker::loop function on lines 231-232 of
deal.ii/meshworker/loop.h to
if (integrate_cell)
info.cell.reinit(cell, dof_info.cell);
Cheers,
Andy
On Thursday, January 30, 2020 at 3:39:28 PM UTC-5, Andrew Davis wrote:
>
> Fair point. I reinstalled in Debug mode and now I'm failing at that
> Assert. Here is the error message (using the same code I attached
> previously):
>
> An error occurred in line <2891> of file
> in function
> dealii::types::global_dof_index dealii::FEValuesBase spacedim>::TriaCellIterator::n_dofs_for_dof_handler() const [with int dim =
> 2; int spacedim = 2; dealii::types::global_dof_index = unsigned int]
> The violated condition was:
> false
> Additional information:
> You have previously called the FEValues::reinit function with a
> cell iterator of type Triangulation::cell_iterator. However,
> when you do this, you cannot call some functions in the FEValues
> class, such as the get_function_values/gradients/hessians/third_derivatives
> functions. If you need these functions, then you need to call
> FEValues::reinit with an iterator type that allows to extract
> degrees of freedom, such as DoFHandler::cell_iterator.
>
> I'm going to dig into this further but does anyone know if this is a bug
> or user error? If it is user error does anyone know how to fix this?
>
> Cheers,
> Andy
>
> On Thursday, January 30, 2020 at 2:38:00 PM UTC-5, Bruno Turcksin wrote:
>>
>> On Thursday, January 30, 2020 at 2:28:55 PM UTC-5, Andrew Davis wrote:
>>>
>>>
>>> from the file fe_values.impl.2.inst.in. The Assert(false) seems strange
>>> to me---why doesn't it crash? (I'm in Release mode so that could answer
>>> that). However, should it be calling a different function?
>>>
>>> You should always debug your code in Debug mode. It's very possible that
>> there is an assert that will catch a problem earlier in the code and so the
>> code after that assert makes no sense because you are not supposed to get
>> there.
>>
>> Best,
>>
>> Bruno
>>
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/13e914ec-aa34-4f8e-86fc-84b97b74f9f5%40googlegroups.com.
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
Fair point. I reinstalled in Debug mode and now I'm failing at that Assert. Here is the error message (using the same code I attached previously): An error occurred in line <2891> of file in function dealii::types::global_dof_index dealii::FEValuesBase::TriaCellIterator::n_dofs_for_dof_handler() const [with int dim = 2; int spacedim = 2; dealii::types::global_dof_index = unsigned int] The violated condition was: false Additional information: You have previously called the FEValues::reinit function with a cell iterator of type Triangulation::cell_iterator. However, when you do this, you cannot call some functions in the FEValues class, such as the get_function_values/gradients/hessians/third_derivatives functions. If you need these functions, then you need to call FEValues::reinit with an iterator type that allows to extract degrees of freedom, such as DoFHandler::cell_iterator. I'm going to dig into this further but does anyone know if this is a bug or user error? If it is user error does anyone know how to fix this? Cheers, Andy On Thursday, January 30, 2020 at 2:38:00 PM UTC-5, Bruno Turcksin wrote: > > On Thursday, January 30, 2020 at 2:28:55 PM UTC-5, Andrew Davis wrote: >> >> >> from the file fe_values.impl.2.inst.in. The Assert(false) seems strange >> to me---why doesn't it crash? (I'm in Release mode so that could answer >> that). However, should it be calling a different function? >> >> You should always debug your code in Debug mode. It's very possible that > there is an assert that will catch a problem earlier in the code and so the > code after that assert makes no sense because you are not supposed to get > there. > > Best, > > Bruno > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/e4833a23-0d6d-4ff6-8ba6-f5d1f752b5d9%40googlegroups.com.
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
On Thursday, January 30, 2020 at 2:28:55 PM UTC-5, Andrew Davis wrote: > > > from the file fe_values.impl.2.inst.in. The Assert(false) seems strange > to me---why doesn't it crash? (I'm in Release mode so that could answer > that). However, should it be calling a different function? > > You should always debug your code in Debug mode. It's very possible that there is an assert that will catch a problem earlier in the code and so the code after that assert makes no sense because you are not supposed to get there. Best, Bruno -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/d3cbd9b5-e564-4571-b22f-fdc9fc537e83%40googlegroups.com.
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
I'm continuing to dig into this problem. For some reason the `
get_function_values` is calling the function
for (VEC : VECTOR_TYPES)
{
template
void
FEValuesBase::TriaCellIterator::get_interpolated_dof_values(
const VEC &, Vector &) const
{ //
Assert(false, ExcMessage(message_string));
\}
}
from the file fe_values.impl.2.inst.in. The Assert(false) seems strange to
me---why doesn't it crash? (I'm in Release mode so that could answer that).
However, should it be calling a different function?
Thanks!
On Thursday, January 30, 2020 at 11:31:38 AM UTC-5, Andrew Davis wrote:
>
> As another diagnostic---I added cout statements in the function `
> get_function_values` in fe_values.cc. It looks like the values of the
> input variable `fe_function` are correct but the `dof_values` are always
> set to zero. Specifically:
>
> // get function values of dofs on this cell
> Vector dof_values(dofs_per_cell);
> present_cell->get_interpolated_dof_values(fe_function, dof_values);
> for( unsigned int i=0; i std::cout << "dof_val: " << dof_values[i] << std::endl;
> }
>
> always prints zero.
>
> On Thursday, January 30, 2020 at 11:00:26 AM UTC-5, Andrew Davis wrote:
>>
>> Sure, attached is a *.cpp file that should run. The cout statement on
>> line 87 prints non-zero values for `old_solution` but the cout statement
>> online 92 always prints zero.
>>
>> On Thursday, January 30, 2020 at 10:49:18 AM UTC-5, Wolfgang Bangerth
>> wrote:
>>>
>>> On 1/30/20 8:45 AM, Andrew Davis wrote:
>>> > I thought the same thing---that 'old_solution' would be a zero
>>> vector---but
>>> > when I add the line `std::cout << old_solution << std::endl;` in the
>>> function
>>> > IntegrateCell::operator() (just after the `get_function_values'
>>> call in
>>> > the original post) prints a non-zero vector that I expect.
>>>
>>> That does not sound credible to me. Can you construct a small example
>>> that
>>> does exactly that? I.e., print out, for example, the l2-norm of
>>> old_solution
>>> right before the call to fe_values.get_function_values(), and the
>>> l2-norm of
>>> old_solution_values right after.
>>>
>>> Best
>>> W.
>>>
>>> --
>>>
>>> Wolfgang Bangerth email: bang...@colostate.edu
>>> www:
>>> http://www.math.colostate.edu/~bangerth/
>>>
>>>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/737e8661-1ccd-4eb2-9794-8ac3e61fac30%40googlegroups.com.
Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program
Yup - deal.II did not pick up HYPRE or MUMPS even though you configured PETSc with both (which can be seen by checking the end of PETSc's configure log). I can only think of one more thing to check - try deleting CMakeCache.txt in deal.II's build directory and rerun CMake to see if the cache got stuck in a wrong state. Could you try that? On Thu, Jan 30, 2020 at 11:29 AM Ihar Suvorau wrote: > > I believe this is the correct file. I see the line > "SET(DEAL_II_PETSC_WITH_HYPRE FALSE)” in the file. > > -- > The deal.II project is located at http://www.dealii.org/ > For mailing list/forum options, see > https://groups.google.com/d/forum/dealii?hl=en > --- > You received this message because you are subscribed to the Google Groups > "deal.II User Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dealii+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/32E00408-28C8-4FCD-AC68-ABDF158CDBEC%40gmail.com. > > > Best, > Ihar Suvorau > > > > > On 30. Jan 2020, at 18:22, David Wells wrote: > > > > OK, that also looks right. Could you also send me, from deal.II's > > build directory, > > > > cmake/config/deal.IIConfig.cmake > > > > ? > > > > On Thu, Jan 30, 2020 at 11:05 AM Ihar Suvorau > > wrote: > >> > >> Hi, David, > >> > >> yes, here it is. > >> > >> On Thursday, January 30, 2020 at 6:02:56 PM UTC+2, David Wells wrote: > >>> > >>> Hi Ihar, > >>> > >>> I'm not sure what went wrong - everything looks right except that > >>> deal.II did not find hypre. > >>> > >>> Could you also send > >>> > >>> /Users/ihar/lib/petsc-3.12.3/arch-darwin-c-debug/include/petscconf.h > >>> > >>> to check something else? > >>> > >>> > >>> On Tue, Jan 28, 2020 at 10:14 AM Ihar Suvorau wrote: > > Hi, David, > > okay, please, attaching these files also. > > On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: > > > > Hi Ihar, > > > > It looks like nothing went wrong with PETsc. Would you please also > > send a copy of deal.II's detailed.log and, if available, > > CMakeCache.txt from the build directory? > > > > Thanks, > > David > > > > On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau wrote: > >> > >> Sure, attaching a file, please. > >> > >> On Monday, January 27, 2020 at 5:42:39 PM UTC+2, David Wells wrote: > >>> > >>> Hi Ihar, > >>> > >>> This sounds like something has gone wrong inside either PETSc's or > >>> deal.II's build process. Would you please show us a copy of PETSc's > >>> configure.log? > >>> > >>> Thanks, > >>> David > >>> > >>> On Sun, Jan 26, 2020 at 6:59 AM Ihar Suvorau > >>> wrote: > > Not yet, I have a running version via docker images though. I'll try > the bundle also, thank you, before I was thinking that it shouldn't > support parallel programming, but now I see it is configured with > "DEAL_II_WITH_MPI set up with external dependencies" and > "DEAL_II_WITH_PETSC set up with external dependencies" and has all > packages installed. > > But I'm still interested in solving the issue with "Your PETSc > installation does not include a copy of the hypre package necessary > for this preconditioner" when I do have the hypre package installed > via the option "--download-hypre=1" while configuring PETSc. > > On Sunday, January 26, 2020 at 11:48:21 AM UTC+2, luca.heltai wrote: > > > > Did you try the pre-compiled deal.II package? > > > > Both > > > > dealii-9.1.1-clang-9.0.0.dmg > > > > and > > > > dealii-9.1.1-catalina-haswell-ro.dmg.zip > > > > > > from https://github.com/dealii/dealii/releases/tag/v9.1.1 > > > > should work. > > > > Luca. > > > >> On 25 Jan 2020, at 21:29, Ihar Suvorau wrote: > >> > >> > >> Software: > >>• macOS Catalina 10.15.2 > >>• deal.ii 9.1.1 > >>• PETSc 3.12 > >> Question: > >> > >> Hey, does somebody know a potential reason for this message while > >> running a well-compiled step-40 program: > >> > >> ihar@husky build3 % ./step-40 > >> > >> > >> Running with PETSc on 1 MPI rank(s)... > >> > >> Cycle 0: > >> > >> Number of active cells: 1024 > >> > >> Number of degrees of freedom: 4225 > >> > >> > >> > >> --- > >> > >> > >> An error occurred in line <543> of file > >> in > >> function > >> > >> void >
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
As another diagnostic---I added cout statements in the function ` get_function_values` in fe_values.cc. It looks like the values of the input variable `fe_function` are correct but the `dof_values` are always set to zero. Specifically: // get function values of dofs on this cell Vector dof_values(dofs_per_cell); present_cell->get_interpolated_dof_values(fe_function, dof_values); for( unsigned int i=0; i > Sure, attached is a *.cpp file that should run. The cout statement on line > 87 prints non-zero values for `old_solution` but the cout statement online > 92 always prints zero. > > On Thursday, January 30, 2020 at 10:49:18 AM UTC-5, Wolfgang Bangerth > wrote: >> >> On 1/30/20 8:45 AM, Andrew Davis wrote: >> > I thought the same thing---that 'old_solution' would be a zero >> vector---but >> > when I add the line `std::cout << old_solution << std::endl;` in the >> function >> > IntegrateCell::operator() (just after the `get_function_values' >> call in >> > the original post) prints a non-zero vector that I expect. >> >> That does not sound credible to me. Can you construct a small example >> that >> does exactly that? I.e., print out, for example, the l2-norm of >> old_solution >> right before the call to fe_values.get_function_values(), and the l2-norm >> of >> old_solution_values right after. >> >> Best >> W. >> >> -- >> >> Wolfgang Bangerth email: bang...@colostate.edu >> www: http://www.math.colostate.edu/~bangerth/ >> >> -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/44c6c2a8-ec56-4a1c-99ab-6971fb5146cf%40googlegroups.com.
Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program
I believe this is the correct file. I see the line "SET(DEAL_II_PETSC_WITH_HYPRE FALSE)” in the file. -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/32E00408-28C8-4FCD-AC68-ABDF158CDBEC%40gmail.com. deal.IIConfig.cmake Description: Binary data Best, Ihar Suvorau > On 30. Jan 2020, at 18:22, David Wells wrote: > > OK, that also looks right. Could you also send me, from deal.II's > build directory, > > cmake/config/deal.IIConfig.cmake > > ? > > On Thu, Jan 30, 2020 at 11:05 AM Ihar Suvorau wrote: >> >> Hi, David, >> >> yes, here it is. >> >> On Thursday, January 30, 2020 at 6:02:56 PM UTC+2, David Wells wrote: >>> >>> Hi Ihar, >>> >>> I'm not sure what went wrong - everything looks right except that >>> deal.II did not find hypre. >>> >>> Could you also send >>> >>> /Users/ihar/lib/petsc-3.12.3/arch-darwin-c-debug/include/petscconf.h >>> >>> to check something else? >>> >>> >>> On Tue, Jan 28, 2020 at 10:14 AM Ihar Suvorau wrote: Hi, David, okay, please, attaching these files also. On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: > > Hi Ihar, > > It looks like nothing went wrong with PETsc. Would you please also > send a copy of deal.II's detailed.log and, if available, > CMakeCache.txt from the build directory? > > Thanks, > David > > On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau wrote: >> >> Sure, attaching a file, please. >> >> On Monday, January 27, 2020 at 5:42:39 PM UTC+2, David Wells wrote: >>> >>> Hi Ihar, >>> >>> This sounds like something has gone wrong inside either PETSc's or >>> deal.II's build process. Would you please show us a copy of PETSc's >>> configure.log? >>> >>> Thanks, >>> David >>> >>> On Sun, Jan 26, 2020 at 6:59 AM Ihar Suvorau wrote: Not yet, I have a running version via docker images though. I'll try the bundle also, thank you, before I was thinking that it shouldn't support parallel programming, but now I see it is configured with "DEAL_II_WITH_MPI set up with external dependencies" and "DEAL_II_WITH_PETSC set up with external dependencies" and has all packages installed. But I'm still interested in solving the issue with "Your PETSc installation does not include a copy of the hypre package necessary for this preconditioner" when I do have the hypre package installed via the option "--download-hypre=1" while configuring PETSc. On Sunday, January 26, 2020 at 11:48:21 AM UTC+2, luca.heltai wrote: > > Did you try the pre-compiled deal.II package? > > Both > > dealii-9.1.1-clang-9.0.0.dmg > > and > > dealii-9.1.1-catalina-haswell-ro.dmg.zip > > > from https://github.com/dealii/dealii/releases/tag/v9.1.1 > > should work. > > Luca. > >> On 25 Jan 2020, at 21:29, Ihar Suvorau wrote: >> >> >> Software: >>• macOS Catalina 10.15.2 >>• deal.ii 9.1.1 >>• PETSc 3.12 >> Question: >> >> Hey, does somebody know a potential reason for this message while >> running a well-compiled step-40 program: >> >> ihar@husky build3 % ./step-40 >> >> >> Running with PETSc on 1 MPI rank(s)... >> >> Cycle 0: >> >> Number of active cells: 1024 >> >> Number of degrees of freedom: 4225 >> >> >> >> --- >> >> >> An error occurred in line <543> of file >> in >> function >> >> void >> dealii::PETScWrappers::PreconditionBoomerAMG::initialize(const >> dealii::PETScWrappers::MatrixBase &, const >> dealii::PETScWrappers::PreconditionBoomerAMG::AdditionalData &) >> >> The violated condition was: >> >> false >> >> Additional information: >> >> Your PETSc installation does not include a copy of the hypre >> package necessary for this preconditioner. >> >> >> >> Stacktrace: >> >> --- >> >> #0 2
Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program
OK, that also looks right. Could you also send me, from deal.II's build directory, cmake/config/deal.IIConfig.cmake ? On Thu, Jan 30, 2020 at 11:05 AM Ihar Suvorau wrote: > > Hi, David, > > yes, here it is. > > On Thursday, January 30, 2020 at 6:02:56 PM UTC+2, David Wells wrote: >> >> Hi Ihar, >> >> I'm not sure what went wrong - everything looks right except that >> deal.II did not find hypre. >> >> Could you also send >> >> /Users/ihar/lib/petsc-3.12.3/arch-darwin-c-debug/include/petscconf.h >> >> to check something else? >> >> >> On Tue, Jan 28, 2020 at 10:14 AM Ihar Suvorau wrote: >> > >> > Hi, David, >> > >> > okay, please, attaching these files also. >> > >> > On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: >> >> >> >> Hi Ihar, >> >> >> >> It looks like nothing went wrong with PETsc. Would you please also >> >> send a copy of deal.II's detailed.log and, if available, >> >> CMakeCache.txt from the build directory? >> >> >> >> Thanks, >> >> David >> >> >> >> On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau wrote: >> >> > >> >> > Sure, attaching a file, please. >> >> > >> >> > On Monday, January 27, 2020 at 5:42:39 PM UTC+2, David Wells wrote: >> >> >> >> >> >> Hi Ihar, >> >> >> >> >> >> This sounds like something has gone wrong inside either PETSc's or >> >> >> deal.II's build process. Would you please show us a copy of PETSc's >> >> >> configure.log? >> >> >> >> >> >> Thanks, >> >> >> David >> >> >> >> >> >> On Sun, Jan 26, 2020 at 6:59 AM Ihar Suvorau >> >> >> wrote: >> >> >> > >> >> >> > Not yet, I have a running version via docker images though. I'll try >> >> >> > the bundle also, thank you, before I was thinking that it shouldn't >> >> >> > support parallel programming, but now I see it is configured with >> >> >> > "DEAL_II_WITH_MPI set up with external dependencies" and >> >> >> > "DEAL_II_WITH_PETSC set up with external dependencies" and has all >> >> >> > packages installed. >> >> >> > >> >> >> > But I'm still interested in solving the issue with "Your PETSc >> >> >> > installation does not include a copy of the hypre package necessary >> >> >> > for this preconditioner" when I do have the hypre package installed >> >> >> > via the option "--download-hypre=1" while configuring PETSc. >> >> >> > >> >> >> > On Sunday, January 26, 2020 at 11:48:21 AM UTC+2, luca.heltai wrote: >> >> >> >> >> >> >> >> Did you try the pre-compiled deal.II package? >> >> >> >> >> >> >> >> Both >> >> >> >> >> >> >> >> dealii-9.1.1-clang-9.0.0.dmg >> >> >> >> >> >> >> >> and >> >> >> >> >> >> >> >> dealii-9.1.1-catalina-haswell-ro.dmg.zip >> >> >> >> >> >> >> >> >> >> >> >> from https://github.com/dealii/dealii/releases/tag/v9.1.1 >> >> >> >> >> >> >> >> should work. >> >> >> >> >> >> >> >> Luca. >> >> >> >> >> >> >> >> > On 25 Jan 2020, at 21:29, Ihar Suvorau wrote: >> >> >> >> > >> >> >> >> > >> >> >> >> > Software: >> >> >> >> > • macOS Catalina 10.15.2 >> >> >> >> > • deal.ii 9.1.1 >> >> >> >> > • PETSc 3.12 >> >> >> >> > Question: >> >> >> >> > >> >> >> >> > Hey, does somebody know a potential reason for this message while >> >> >> >> > running a well-compiled step-40 program: >> >> >> >> > >> >> >> >> > ihar@husky build3 % ./step-40 >> >> >> >> > >> >> >> >> > >> >> >> >> > Running with PETSc on 1 MPI rank(s)... >> >> >> >> > >> >> >> >> > Cycle 0: >> >> >> >> > >> >> >> >> > Number of active cells: 1024 >> >> >> >> > >> >> >> >> > Number of degrees of freedom: 4225 >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > --- >> >> >> >> > >> >> >> >> > >> >> >> >> > An error occurred in line <543> of file >> >> >> >> > >> >> >> >> > in function >> >> >> >> > >> >> >> >> >void >> >> >> >> > dealii::PETScWrappers::PreconditionBoomerAMG::initialize(const >> >> >> >> > dealii::PETScWrappers::MatrixBase &, const >> >> >> >> > dealii::PETScWrappers::PreconditionBoomerAMG::AdditionalData &) >> >> >> >> > >> >> >> >> > The violated condition was: >> >> >> >> > >> >> >> >> >false >> >> >> >> > >> >> >> >> > Additional information: >> >> >> >> > >> >> >> >> >Your PETSc installation does not include a copy of the hypre >> >> >> >> > package necessary for this preconditioner. >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > Stacktrace: >> >> >> >> > >> >> >> >> > --- >> >> >> >> > >> >> >> >> > #0 2 libdeal_II.g.9.1.1.dylib0x00011188b86f >> >> >> >> > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE >> >> >> >> > + 95: 2 libdeal_II.g.9.1.1.dylib0x00011188b86f >> >> >> >> > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE >> >> >> >> > >> >> >> >> > #1 3 step-40 0x00010643881a >> >> >> >> > _ZN6Step4014LaplaceProblemILi2EE5solveEv + 266: 3 step-40 >> >> >> >> >
Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program
Hi, David, yes, here it is. On Thursday, January 30, 2020 at 6:02:56 PM UTC+2, David Wells wrote: > > Hi Ihar, > > I'm not sure what went wrong - everything looks right except that > deal.II did not find hypre. > > Could you also send > > /Users/ihar/lib/petsc-3.12.3/arch-darwin-c-debug/include/petscconf.h > > to check something else? > > > On Tue, Jan 28, 2020 at 10:14 AM Ihar Suvorau > wrote: > > > > Hi, David, > > > > okay, please, attaching these files also. > > > > On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: > >> > >> Hi Ihar, > >> > >> It looks like nothing went wrong with PETsc. Would you please also > >> send a copy of deal.II's detailed.log and, if available, > >> CMakeCache.txt from the build directory? > >> > >> Thanks, > >> David > >> > >> On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau > wrote: > >> > > >> > Sure, attaching a file, please. > >> > > >> > On Monday, January 27, 2020 at 5:42:39 PM UTC+2, David Wells wrote: > >> >> > >> >> Hi Ihar, > >> >> > >> >> This sounds like something has gone wrong inside either PETSc's or > >> >> deal.II's build process. Would you please show us a copy of PETSc's > >> >> configure.log? > >> >> > >> >> Thanks, > >> >> David > >> >> > >> >> On Sun, Jan 26, 2020 at 6:59 AM Ihar Suvorau > wrote: > >> >> > > >> >> > Not yet, I have a running version via docker images though. I'll > try the bundle also, thank you, before I was thinking that it shouldn't > support parallel programming, but now I see it is configured with > "DEAL_II_WITH_MPI set up with external dependencies" and > "DEAL_II_WITH_PETSC set up with external dependencies" and has all packages > installed. > >> >> > > >> >> > But I'm still interested in solving the issue with "Your PETSc > installation does not include a copy of the hypre package necessary for > this preconditioner" when I do have the hypre package installed via the > option "--download-hypre=1" while configuring PETSc. > >> >> > > >> >> > On Sunday, January 26, 2020 at 11:48:21 AM UTC+2, luca.heltai > wrote: > >> >> >> > >> >> >> Did you try the pre-compiled deal.II package? > >> >> >> > >> >> >> Both > >> >> >> > >> >> >> dealii-9.1.1-clang-9.0.0.dmg > >> >> >> > >> >> >> and > >> >> >> > >> >> >> dealii-9.1.1-catalina-haswell-ro.dmg.zip > >> >> >> > >> >> >> > >> >> >> from https://github.com/dealii/dealii/releases/tag/v9.1.1 > >> >> >> > >> >> >> should work. > >> >> >> > >> >> >> Luca. > >> >> >> > >> >> >> > On 25 Jan 2020, at 21:29, Ihar Suvorau > wrote: > >> >> >> > > >> >> >> > > >> >> >> > Software: > >> >> >> > • macOS Catalina 10.15.2 > >> >> >> > • deal.ii 9.1.1 > >> >> >> > • PETSc 3.12 > >> >> >> > Question: > >> >> >> > > >> >> >> > Hey, does somebody know a potential reason for this message > while running a well-compiled step-40 program: > >> >> >> > > >> >> >> > ihar@husky build3 % ./step-40 > >> >> >> > > >> >> >> > > >> >> >> > Running with PETSc on 1 MPI rank(s)... > >> >> >> > > >> >> >> > Cycle 0: > >> >> >> > > >> >> >> > Number of active cells: 1024 > >> >> >> > > >> >> >> > Number of degrees of freedom: 4225 > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > --- > >> >> >> > > >> >> >> > > >> >> >> > An error occurred in line <543> of file > in function > >> >> >> > > >> >> >> >void > dealii::PETScWrappers::PreconditionBoomerAMG::initialize(const > dealii::PETScWrappers::MatrixBase &, const > dealii::PETScWrappers::PreconditionBoomerAMG::AdditionalData &) > >> >> >> > > >> >> >> > The violated condition was: > >> >> >> > > >> >> >> >false > >> >> >> > > >> >> >> > Additional information: > >> >> >> > > >> >> >> >Your PETSc installation does not include a copy of the hypre > package necessary for this preconditioner. > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> > Stacktrace: > >> >> >> > > >> >> >> > --- > >> >> >> > > >> >> >> > #0 2 libdeal_II.g.9.1.1.dylib0x00011188b86f > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE > > + 95: 2 libdeal_II.g.9.1.1.dylib0x00011188b86f > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE > > > >> >> >> > > >> >> >> > #1 3 step-40 0x00010643881a > _ZN6Step4014LaplaceProblemILi2EE5solveEv + 266: 3 step-40 > 0x00010643881a _ZN6Step4014LaplaceProblemILi2EE5solveEv > >> >> >> > > >> >> >> > #2 4 step-40 0x00010642e633 > _ZN6Step4014LaplaceProblemILi2EE3runEv + 451: 4 step-40 > 0x00010642e633 _ZN6Step4014LaplaceProblemILi2EE3runEv > >> >> >> > > >> >> >> > #3 5 step-40 0x00010642e23a >
Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program
Hi Ihar, I'm not sure what went wrong - everything looks right except that deal.II did not find hypre. Could you also send /Users/ihar/lib/petsc-3.12.3/arch-darwin-c-debug/include/petscconf.h to check something else? On Tue, Jan 28, 2020 at 10:14 AM Ihar Suvorau wrote: > > Hi, David, > > okay, please, attaching these files also. > > On Tuesday, January 28, 2020 at 4:18:44 PM UTC+2, David Wells wrote: >> >> Hi Ihar, >> >> It looks like nothing went wrong with PETsc. Would you please also >> send a copy of deal.II's detailed.log and, if available, >> CMakeCache.txt from the build directory? >> >> Thanks, >> David >> >> On Mon, Jan 27, 2020 at 5:59 PM Ihar Suvorau wrote: >> > >> > Sure, attaching a file, please. >> > >> > On Monday, January 27, 2020 at 5:42:39 PM UTC+2, David Wells wrote: >> >> >> >> Hi Ihar, >> >> >> >> This sounds like something has gone wrong inside either PETSc's or >> >> deal.II's build process. Would you please show us a copy of PETSc's >> >> configure.log? >> >> >> >> Thanks, >> >> David >> >> >> >> On Sun, Jan 26, 2020 at 6:59 AM Ihar Suvorau wrote: >> >> > >> >> > Not yet, I have a running version via docker images though. I'll try >> >> > the bundle also, thank you, before I was thinking that it shouldn't >> >> > support parallel programming, but now I see it is configured with >> >> > "DEAL_II_WITH_MPI set up with external dependencies" and >> >> > "DEAL_II_WITH_PETSC set up with external dependencies" and has all >> >> > packages installed. >> >> > >> >> > But I'm still interested in solving the issue with "Your PETSc >> >> > installation does not include a copy of the hypre package necessary for >> >> > this preconditioner" when I do have the hypre package installed via the >> >> > option "--download-hypre=1" while configuring PETSc. >> >> > >> >> > On Sunday, January 26, 2020 at 11:48:21 AM UTC+2, luca.heltai wrote: >> >> >> >> >> >> Did you try the pre-compiled deal.II package? >> >> >> >> >> >> Both >> >> >> >> >> >> dealii-9.1.1-clang-9.0.0.dmg >> >> >> >> >> >> and >> >> >> >> >> >> dealii-9.1.1-catalina-haswell-ro.dmg.zip >> >> >> >> >> >> >> >> >> from https://github.com/dealii/dealii/releases/tag/v9.1.1 >> >> >> >> >> >> should work. >> >> >> >> >> >> Luca. >> >> >> >> >> >> > On 25 Jan 2020, at 21:29, Ihar Suvorau wrote: >> >> >> > >> >> >> > >> >> >> > Software: >> >> >> > • macOS Catalina 10.15.2 >> >> >> > • deal.ii 9.1.1 >> >> >> > • PETSc 3.12 >> >> >> > Question: >> >> >> > >> >> >> > Hey, does somebody know a potential reason for this message while >> >> >> > running a well-compiled step-40 program: >> >> >> > >> >> >> > ihar@husky build3 % ./step-40 >> >> >> > >> >> >> > >> >> >> > Running with PETSc on 1 MPI rank(s)... >> >> >> > >> >> >> > Cycle 0: >> >> >> > >> >> >> > Number of active cells: 1024 >> >> >> > >> >> >> > Number of degrees of freedom: 4225 >> >> >> > >> >> >> > >> >> >> > >> >> >> > --- >> >> >> > >> >> >> > >> >> >> > An error occurred in line <543> of file >> >> >> > in >> >> >> > function >> >> >> > >> >> >> >void >> >> >> > dealii::PETScWrappers::PreconditionBoomerAMG::initialize(const >> >> >> > dealii::PETScWrappers::MatrixBase &, const >> >> >> > dealii::PETScWrappers::PreconditionBoomerAMG::AdditionalData &) >> >> >> > >> >> >> > The violated condition was: >> >> >> > >> >> >> >false >> >> >> > >> >> >> > Additional information: >> >> >> > >> >> >> >Your PETSc installation does not include a copy of the hypre >> >> >> > package necessary for this preconditioner. >> >> >> > >> >> >> > >> >> >> > >> >> >> > Stacktrace: >> >> >> > >> >> >> > --- >> >> >> > >> >> >> > #0 2 libdeal_II.g.9.1.1.dylib0x00011188b86f >> >> >> > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE >> >> >> > + 95: 2 libdeal_II.g.9.1.1.dylib0x00011188b86f >> >> >> > _ZN6dealii13PETScWrappers21PreconditionBoomerAMG10initializeERKNS0_10MatrixBaseERKNS1_14AdditionalDataE >> >> >> > >> >> >> > #1 3 step-40 0x00010643881a >> >> >> > _ZN6Step4014LaplaceProblemILi2EE5solveEv + 266: 3 step-40 >> >> >> >0x00010643881a >> >> >> > _ZN6Step4014LaplaceProblemILi2EE5solveEv >> >> >> > >> >> >> > #2 4 step-40 0x00010642e633 >> >> >> > _ZN6Step4014LaplaceProblemILi2EE3runEv + 451: 4 step-40 >> >> >> > 0x00010642e633 >> >> >> > _ZN6Step4014LaplaceProblemILi2EE3runEv >> >> >> > >> >> >> > #3 5 step-40 0x00010642e23a main >> >> >> > + 106: 5 step-40 0x00010642e23a >> >> >> > main >> >> >> > >> >> >> > #4 6 libdyld.dylib 0x7fff6350f7fd start >> >> >> > + 1: 6 libdyld.dylib 0x7fff6350f7fd start >>
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
Sure, attached is a *.cpp file that should run. The cout statement on line
87 prints non-zero values for `old_solution` but the cout statement online
92 always prints zero.
On Thursday, January 30, 2020 at 10:49:18 AM UTC-5, Wolfgang Bangerth wrote:
>
> On 1/30/20 8:45 AM, Andrew Davis wrote:
> > I thought the same thing---that 'old_solution' would be a zero
> vector---but
> > when I add the line `std::cout << old_solution << std::endl;` in the
> function
> > IntegrateCell::operator() (just after the `get_function_values'
> call in
> > the original post) prints a non-zero vector that I expect.
>
> That does not sound credible to me. Can you construct a small example that
> does exactly that? I.e., print out, for example, the l2-norm of
> old_solution
> right before the call to fe_values.get_function_values(), and the l2-norm
> of
> old_solution_values right after.
>
> Best
> W.
>
> --
>
> Wolfgang Bangerth email: bang...@colostate.edu
>
> www: http://www.math.colostate.edu/~bangerth/
>
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/4dd7f499-1eeb-41b2-bed4-d715354007d7%40googlegroups.com.
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
using namespace dealii;
/// The initial conditions for the mass
template
class InitialConditionMass : public dealii::Function {
public:
InitialConditionMass() = default;
virtual ~InitialConditionMass() = default;
virtual double value(dealii::Point const& p, const unsigned int component=0) const override;
private:
};
template
double InitialConditionMass::value(dealii::Point const& p, const unsigned int component) const {
(void)component;
Assert(component==0, ExcIndexRange(component, 0, 1));
return p(0);
}
template
class IntegrateCell {
public:
IntegrateCell(dealii::Vector const& old_solution);
virtual ~IntegrateCell() = default;
void operator()(dealii::MeshWorker::DoFInfo& dinfo, dealii::MeshWorker::IntegrationInfo& info) const;
private:
/// Store a constant reference to the old solution
const dealii::Vector& old_solution;
};
template
IntegrateCell::IntegrateCell(Vector const& old_solution) : old_solution(old_solution) {}
template
void IntegrateCell::operator()(MeshWorker::DoFInfo& dinfo, MeshWorker::IntegrationInfo& info) const {
const FEValuesBase& feValues = info.fe_values();
// get the values of the old solution
std::vector old_solution_values(feValues.n_quadrature_points);
feValues.get_function_values(old_solution, old_solution_values);
//std::cout << "old_solution: " << old_solution.l2_norm() << std::endl;
std::cout << "old_solution: " << old_solution << std::endl;
// loop over the quadrature points and compute the advection vector at the current point
for( unsigned int point=0; point
class AdvectionProblem {
public:
/// Default constructor
AdvectionProblem();
virtual ~AdvectionProblem() = default;
void SetupSystem();
void AssembleSystem();
void Run();
private:
/// Set up the initial condition
/**
@param[in] vec Set the intial condition onto this vector
*/
void SetInitialCondition(dealii::Vector& vec);
/// Globally refine the mesh
/**
@param[in] nrefine The number of global refinements
*/
void InitializeGrid(unsigned int const nrefine);
using DoFInfo = dealii::MeshWorker::DoFInfo;
using CellInfo = dealii::MeshWorker::IntegrationInfo;
dealii::Triangulation triangulation;
const dealii::MappingQ1 mapping;
dealii::FE_DGQ fe;
dealii::DoFHandler dofHandler;
dealii::AffineConstraints constraints;
dealii::SparsityPattern sparsityPattern;
dealii::SparseMatrix systemMatrix;
/// The solution to the advection equation at the current timestep
dealii::Vector solution;
/// The solution to the advection equation at the previous timestep
dealii::Vector old_solution;
dealii::Vector rhs;
/// The length of each timestep
const double timeStep = 1.0/3.0;
/// The current time
double currTime;
/// The current timestep
unsigned int step = 0;
/// The final time
const double finalTime = 1.0;
};
template
AdvectionProblem::AdvectionProblem() : mapping(), fe(1), dofHandler(triangulation), currTime(timeStep) {
// initialize a square grid and refine global
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
On 1/30/20 8:45 AM, Andrew Davis wrote: > I thought the same thing---that 'old_solution' would be a zero vector---but > when I add the line `std::cout << old_solution << std::endl;` in the function > IntegrateCell::operator() (just after the `get_function_values' call in > the original post) prints a non-zero vector that I expect. That does not sound credible to me. Can you construct a small example that does exactly that? I.e., print out, for example, the l2-norm of old_solution right before the call to fe_values.get_function_values(), and the l2-norm of old_solution_values right after. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/34bf95a7-7fca-c04f-6f7c-b97deb97e1bf%40colostate.edu.
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
I thought the same thing---that 'old_solution' would be a zero vector---but when I add the line `std::cout << old_solution << std::endl;` in the function IntegrateCell::operator() (just after the ` get_function_values' call in the original post) prints a non-zero vector that I expect. On Thursday, January 30, 2020 at 10:39:27 AM UTC-5, Wolfgang Bangerth wrote: > > On 1/29/20 1:14 PM, Andrew Davis wrote: > > * > > * > > *For some reason the feValues.get_function_values(old_solution, > > old_solution_values); call in the CellIntegrator function always sets > the > > old_solution_values to zero. Does anyone see what I'm doing wrong?* > > So the output of this function is wrong. Is the input correct? My guess > would > be that if you looked at 'old_solution', you'd find that it's a zero > vector. > Why that is so I don't know, but it's something you should be able to > trace > back to its source. > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/ae51cb34-3209-482a-afbd-c33922b2d78c%40googlegroups.com.
Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop
On 1/29/20 1:14 PM, Andrew Davis wrote: > * > * > *For some reason the feValues.get_function_values(old_solution, > old_solution_values); call in the CellIntegrator function always sets the > old_solution_values to zero. Does anyone see what I'm doing wrong?* So the output of this function is wrong. Is the input correct? My guess would be that if you looked at 'old_solution', you'd find that it's a zero vector. Why that is so I don't know, but it's something you should be able to trace back to its source. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/2d587eb8-9ad5-560a-3072-b34894702008%40colostate.edu.
[deal.II] Re: Getting old solution values at quadrature points using MeshWorker::loop
I'm not sure if this is helpful but as a diagnostic, replacing
MeshWorker::loop with this loop that I wrote myself:
const QGauss quadrature_formula(fe.degree + 1);
const unsigned int n_q_points = quadrature_formula.size();
FEValues fe_values(fe, quadrature_formula, update_values |
update_JxW_values);
std::vector solution_values(n_q_points);
for( const auto& cell : dofHandler.active_cell_iterators() ) {
fe_values.reinit(cell);
fe_values.get_function_values(old_solution, solution_values);
for( unsigned int i=0; i
> I'm trying to implement a time-dependent solver that assembles the system
> using the MeshWorker::loop tool. However, I cannot figure out how get the
> values of the solution at the previous timestep at each quadrature point.
>
> Currently, I store the old solution in a class called "AdvectionProblem"
> such that---I've left out some code in the interest of brevity.
>
> template
> class AdvectionProblem {
> public:
> ...
> void AssembleSystem()
> private:
> ...
> Vector old_solution;
> DoFHandler dofHandler;
> };
>
> Since we need the old_solution values to assemble the system, I create a
> CellIntegrator class that MeshWorker::loop can use to integrate over each
> cell (I also create similar objects for faces/boundaries):
>
> template
> class IntegrateCell {
> public:
> IntegrateCell(dealii::Vector const& old_solution);
>
> virtual ~IntegrateCell() = default;
>
> void operator()(dealii::MeshWorker::DoFInfo& dinfo,
> dealii::MeshWorker::IntegrationInfo& info) const;
>
> private:
>
> /// Store a constant reference to the old solution
> const dealii::Vector& old_solution;
> };
>
> template
> IntegrateCell::IntegrateCell(Vector const& old_solution) :
> old_solution(old_solution) {}
>
> template
> void IntegrateCell::operator()(MeshWorker::DoFInfo& dinfo,
> MeshWorker::IntegrationInfo& info) const {
> // get some useful objects
> const FEValuesBase& feValues = info.fe_values();
> FullMatrix& localMatrix = dinfo.matrix(0).matrix;
> Vector& localVector = dinfo.vector(0).block(0);
> const std::vector& JxW = feValues.get_JxW_values();
>
> // get the values of the old solution
> std::vector old_solution_values(feValues.n_quadrature_points);
> feValues.get_function_values(old_solution, old_solution_values);
>
>
> *// these are non-zero, IngtegrateCell is correctly getting the
> old_solution std::cout << old_solution << std::endl;*
>
> // loop over the quadrature points and compute the advection vector at
> the current point
> for( unsigned int point=0; point {
>
> *// these are always all zero*
> *std::cout << "value: " << old_solution_values[point] << std::endl;*
> }
> }
>
> I then try to assemble the system using the MeshWorker::loop tool:
>
> template
> void AdvectionProblem::AssembleSystem() {
> // an object that knows about data structures and local integration
> MeshWorker::IntegrationInfoBox infoBox;
>
> // initialize the quadrature formula
> const unsigned int nGauss = dofHandler.get_fe().degree + 1;
> infoBox.initialize_gauss_quadrature(nGauss, nGauss, nGauss);
>
> // these are the values we need to integrate our system
> infoBox.initialize_update_flags();
> const UpdateFlags updateFlags = update_quadrature_points | update_values
> | update_gradients | update_JxW_values;
> infoBox.add_update_flags(updateFlags, true, true, true, true);
>
> // initialize the finite element values
> infoBox.initialize(fe, mapping);
>
> // create an object that forwards local data to the assembler
> MeshWorker::DoFInfo dofInfo(dofHandler);
>
> // create teh assembler---tell it where to put local data
> MeshWorker::Assembler::SystemSimple, Vector
> > assembler;
> assembler.initialize(systemMatrix, rhs);
>
> IntegrateCell cellIntegration(old_solution);
>
> *MeshWorker::loop,
> MeshWorker::IntegrationInfoBox >(dofHandler.begin_active(),
> dofHandler.end(), dofInfo, infoBox, cellIntegration, nullptr, nullptr,
> assembler);*
> }
>
> *For some reason the feValues.get_function_values(old_solution,
> old_solution_values); call in the CellIntegrator function always sets the
> old_solution_values to zero. Does anyone see what I'm doing wrong?*
>
>
> Thanks!
>
--
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see
https://groups.google.com/d/forum/dealii?hl=en
---
You received this message because you are subscribed to the Google Groups
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/4ea6059f-177c-4a7c-8462-5a5482b31b38%40googlegroups.com.
Re: [deal.II] Difference between laplace-application through a matrix and through get_function_gradients()
The reason for getting wrong results was a forgotten '+'. I just inserted the values of the right hand side into the cell vector, but never added them up, unlike what I did with the matrix. Therefore I got wrong values for the right hand side. After this was a simple writing error, and (as far as I can see) nothing which can be used by others, I decided to delete the question. Therefore, the original question is not relevant anymore, either. Thanks! Am Mittwoch, 29. Januar 2020 23:19:50 UTC+1 schrieb Wolfgang Bangerth: > > On 1/20/20 7:59 AM, 'Maxi Miller' via deal.II User Group wrote: > > > > I wrote a short test program which should solve the diffusion equation > > using the time-stepping class, and implemented both methods. When > > calculating the matrix and applying it to my solution vector, I get a > > different result compared to reading the gradients from the solution > > with get_function_gradients() and multiplying it with the gradients > > returned by shape_grad(). The results obtained from the matrix > > multiplication are correct compared to the expected solution, the > > results obtained from the direct approach are not. Why is that? > > Maxi -- if I understand you correctly, you're asking what the difference > is between computing > >F_i = \int \grad\varphi_i . grad u_h > > and > >F_i = (AU)_i > > where A=Laplace matrix, U=coefficient vector corresponding to u_h. > > There shouldn't be a difference in principle, but you have to pay > attention to what hanging nodes and Dirichlet boundary conditions do. In > particular, you might have to call F.condense() in the first case. > > You only say that the results are different, but not *how* they are > different. Have you looked at that? Are these two vectors different only > in hanging nodes? Only for shape functions at the boundary? > > Best > W. > > -- > > Wolfgang Bangerth email: bang...@colostate.edu > > www: http://www.math.colostate.edu/~bangerth/ > -- The deal.II project is located at http://www.dealii.org/ For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en --- You received this message because you are subscribed to the Google Groups "deal.II User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/327036e0-7343-488e-949e-8ce1bb42f829%40googlegroups.com.
