Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Bruno Turcksin
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

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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,

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-30 Thread David Wells
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

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-30 Thread Ihar Suvorau
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

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-30 Thread David Wells
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

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-30 Thread Ihar Suvorau
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 > >

Re: [deal.II] "PETSc installation does not include a copy of the hypre package" while running the step-40 program

2020-01-30 Thread David Wells
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, > >

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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:

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Wolfgang Bangerth
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)

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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

Re: [deal.II] Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Wolfgang Bangerth
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

[deal.II] Re: Getting old solution values at quadrature points using MeshWorker::loop

2020-01-30 Thread Andrew Davis
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 |

Re: [deal.II] Difference between laplace-application through a matrix and through get_function_gradients()

2020-01-30 Thread 'Maxi Miller' via deal.II User Group
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