Luca,
Thanks for the idea. Conceptually I don't understand how a shared_ptr
solves my problem. I can resize
std::vector<std::shared_ptr<dealii::Functions::ParsedFunction<dim>>>; but
all of the shared pointers are empty. I imagine that they are supposed to
point to ParsedFunction<dim> objects that I've instantiated somewhere.
That being said, I think you are leading me in the correct direction. In
the following test code, "default.prm" is successfully generated with the
four parsed function sections. It seg faults when I call parse_parameters;
so I'm still debugging:
#include <deal.II/base/parsed_function.h>
#include <iostream>
#include <assert.h>
int main(int /*argc*/, char** /*argv*/)
{
const unsigned int dim = 2;
const unsigned int function_count = 4;
std::vector<std::shared_ptr<dealii::Functions::ParsedFunction<dim>>>
function_pointers;
function_pointers.resize(function_count);
dealii::ParameterHandler prm;
for (unsigned int f = 0; f < function_count; ++f)
{
prm.enter_subsection("parsed_function_"+std::to_string(f));
{
function_pointers[f]->declare_parameters(prm);
}
prm.leave_subsection();
}
prm.read_input("default.prm", false, true);
for (unsigned int f = 0; f < function_count; ++f)
{
prm.enter_subsection("parsed_function_"+std::to_string(f));
{
function_pointers[f]->parse_parameters(prm);
}
prm.leave_subsection();
}
return 0;
}
Thanks,
Alex
On Wednesday, March 22, 2017 at 4:45:03 PM UTC+1, Luca Heltai wrote:
>
> Hi Alex,
>
> I’d use a vector of
>
> std::vector<std_cxx11::shared_pointer<ParsedFunction<dim> > > v;
>
> which are light objects, and can be resized and reshaped. Whenever you do
> a push_back, you’d have to use
>
> v.push_back(std_cxx11::shared_pointer<ParsedFunction<dim>(new
> ParsedFunction<dim>(…) );
>
> then
>
> v[i]->value(…)
>
> would work.
>
>
> > On 22 Mar 2017, at 16:31, Alex Zimmerman <[email protected]
> <javascript:>> wrote:
> >
> > Fundamentally I am trying to allow for a variable number of
> ParsedFunction objects to be specified in a parameter input file. Maybe
> there is a better approach which circumvents my issue below. I can continue
> my work for some time with this being a constant; but as soon as I want to
> extend to 3D or different geometries, this will be a roadblock.
> >
> > I've documented my issue on my GitHub repostiory:
> https://github.com/alexanderzimmerman/nsb-pcm/issues/10 . Here's a copy
> of the text from my issue, which pretty much explains it:
> >
> > Attempting to resize or push_back into a
> std::vector<Functions::ParsedFunction> throws an error within TBB and/or
> mu::Parser, e.g.:
> >
> > In file included from /usr/include/c++/4.8/vector:64:0,
> >
> > from /usr/include/c++/4.8/bits/random.h:34,
> >
> > from /usr/include/c++/4.8/random:50,
> >
> > from /usr/include/c++/4.8/bits/stl_algo.h:65,
> >
> > from /usr/include/c++/4.8/algorithm:62,
> >
> > from
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/concurrent_vector.h:48,
>
>
> >
> > from
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:32,
>
>
> >
> > from
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/base/thread_local_storage.h:23,
>
>
> >
> > from
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/base/logstream.h:23,
>
>
> >
> > from
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/lac/vector.h:21,
>
>
> >
> > from /mnt/c/Users/Alex/UbuntuShared/nsb-pcm/tests/peclet_data.cc:1:
> >
> > /usr/include/c++/4.8/bits/stl_vector.h: In instantiation of
> ‘std::_Vector_base<_Tp, _Alloc>::~_Vector_base() [with _Tp = mu::Parser;
> _Alloc = std::allocatormu::Parser]’:
> >
> > /usr/include/c++/4.8/bits/stl_vector.h:416:33: required from
> ‘std::vector<_Tp, _Alloc>::~vector() [with _Tp = mu::Parser; _Alloc =
> std::allocatormu::Parser]’
> >
> >
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:659:17:
>
> required from ‘void tbb::interface6::internal::ets_element<U,
> ModularSize>::unconstruct() [with U = std::vectormu::Parser; long unsigned
> int ModularSize = 24ul]’
> >
> >
> /home/zimmerman/installed/deal.ii-candi/deal.II-v8.4.2/include/deal.II/bundled/tbb/enumerable_thread_specific.h:729:17:
>
> required from ‘void tbb::interface6::enumerable_thread_specific<T,
> Allocator, ETS_key_type>::unconstruct_locals() [with T =
> std::vectormu::Parser; Allocator =
> tbb::cache_aligned_allocator<std::vectormu::Parser >;
> tbb::ets_key_usage_type ETS_key_type = (tbb::ets_key_usage_type)1u]’
> >
> > Because of this issue, the number of boundaries on the domain must be
> known at compile time (i.e. they can't be set in the input parameter file),
> so that the proper number of ParsedFunction objects can be allocated.
> >
> > Maybe ParsedFunction does not mean these requirements:
> http://stackoverflow.com/questions/12251368/type-requirements-for-stdvectortype
>
> >
> >
> > This might be a bug, or rather missing functionality, in ParsedFunction.
> But I'm still fairly new to deal.II and to C++; so I think it's more likely
> that I'm doing something wrong.
> >
> > The repository includes a branch with test code that reproduces the
> compiler error. The test source code is linked in the issue (on the bugs
> branch).
> >
> > Any ideas?
> >
> >
> > Thanks,
> >
> > Alex
> >
> > --
> > 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] <javascript:>.
> > For more options, visit https://groups.google.com/d/optout.
>
>
--
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.
