I could narrow it down to the function
// same as above for has_partitioners_are_compatible == true
template <
typename VectorType,
typename std::enable_if<has_partitioners_are_compatible<VectorType>::
value,
VectorType>::type * = nullptr>
inline void
check_vector_compatibility(
const VectorType & vec,
const internal::MatrixFreeFunctions::DoFInfo &dof_info)
{
(void)vec;
(void)dof_info;
Assert(vec.partitioners_are_compatible(*dof_info.vector_partitioner),
ExcMessage(
"The parallel layout of the given vector is not "
"compatible with the parallel partitioning in MatrixFree. "
"Use MatrixFree::initialize_dof_vector to get a "
"compatible vector."));
}
located in vector_access_internal.h. Apparently I have a segfault in the
function
template <typename Number, typename MemorySpaceType>
inline bool
Vector<Number, MemorySpaceType>::partitioners_are_compatible(
const Utilities::MPI::Partitioner &part) const
{
return partitioner->is_compatible(part);
}
located in la_parallel_vector.templates.h, and thereby directly stopping
the program without triggering the assert()-function. The direct gdb output
for this function is
#3 0x00007ffff00c0c5c in
dealii::LinearAlgebra::distributed::Vector<double,
dealii::MemorySpace::Host>::partitioners_are_compatible (this=0x0,
part=...) at
~Downloads/git-files/dealii/include/deal.II/lac/la_parallel_vector.templates.h:2021
I am not sure what that means. Could it point to a nullpointer somewhere
(after this=0x0)? Though, when putting a breakpoint to the first function
and printing the involved variables there, I get
(gdb) print dof_info.vector_partitioner
$2 = std::shared_ptr<const dealii::Utilities::MPI::Partitioner> (use count 3
, weak count 0) = {get() = 0x7a60c0}
(gdb) print vec.partitioner
$3 = std::shared_ptr<const dealii::Utilities::MPI::Partitioner> (use count 3
, weak count 0) = {get() = 0x7a60c0}
i.e. no null ptr. Could the problem be there, or somewhere else?
Thanks!
Am Montag, 13. Januar 2020 21:41:54 UTC+1 schrieb Wolfgang Bangerth:
>
> On 1/13/20 8:41 AM, 'Maxi Miller' via deal.II User Group wrote:
> > Therefore, I assume that I have some bugs in my code, but am not
> experienced
> > enough in writing matrix-free code for being able to debug it myself.
> What
> > kind of approach could I do now, or is there simply a glaring bug which
> I did
> > not see yet?
>
> I haven't even looked at the code yet, but for segfaults there is a
> relatively
> simple cure: Run your code in a debugger. A segmentation fault is a
> problem
> where some piece of code tries to access data at an address (typically
> through
> a pointer) that is not readable or writable. The general solution to
> finding
> out what the issue is is to run the code in a debugger -- the debugger
> will
> then stop at the place where the problem happens, and you can inspect all
> of
> the values of the pointers and variables that are live at that location.
> Once
> you see what variable is at fault, the problem is either already obvious,
> or
> you can start to think about how a pointer got the value it has and why.
>
> Best
> W.
>
> --
> ------------------------------------------------------------------------
> 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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/dealii/d55e53b2-a0c8-4cc0-ab84-7521f8b23d81%40googlegroups.com.
