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 kno
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_ha
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 shoul
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, ExcMessa
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 s
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
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 sub
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,
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/inclu
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,
>
> oka
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:
>
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) pri
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 Thursd
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 wr
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_Jx
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
16 matches
Mail list logo