Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-04-25 Thread Alexander Gary Zimmerman
Luca, I finally got around to testing your fix, and now resize works as you 
said it would :) Thanks! Of course it was really easy to do, but I had 
moved on with another branch. Sorry for the delay.


On Thursday, March 23, 2017 at 4:47:58 PM UTC+1, Luca Heltai wrote:
>
> Resizing is fine. It is the equality that won’t work: 
>
> function_pointers[f] = 
>  std::shared_ptr(new 
> dealii::Functions::ParsedFunction())); 
>
> is the correct way to do it. 
>
> L. 
>
>
> > On 23 Mar 2017, at 15:09, Alex Zimmerman  > wrote: 
> > 
> > Also for the record, here's a copy of issue_10_push_back.cc from that 
> repository, which is the example of how to solve my issue: 
> > 
> > #include  
> > 
> > #include  
> > #include  
> > 
> > int main(int /*argc*/, char** /*argv*/) 
> > { 
> > const unsigned int dim = 2; 
> > const unsigned int function_count = 4; 
> > 
> > std::vector> 
> > function_pointers; 
> > 
> > dealii::ParameterHandler prm; 
> > dealii::Point point; 
> > double value; 
> > 
> > for (unsigned int f = 0; f < function_count; ++f) 
> > { 
> > function_pointers.push_back( 
> > std::shared_ptr(new 
> dealii::Functions::ParsedFunction())); 
> > 
> > prm.enter_subsection("parsed_function_"+std::to_string(f)); 
> > { 
> > function_pointers[f]->declare_parameters(prm); 
> > function_pointers[f]->parse_parameters(prm); 
> > } 
> > prm.leave_subsection(); 
> > 
> > function_pointers[f]->value(point, value); 
> > 
> > std::cout << "f(" << point << ") = " << value << std::endl; 
> > } 
> > 
> > return 0; 
> > } 
> > 
> > 
> > On Thursday, March 23, 2017 at 3:05:53 PM UTC+1, Alex Zimmerman wrote: 
> > Timo, thanks for the extra clarification. As I mentioned in my reply to 
> Luca, I don't understand why declare_parameters appeared to succeed in my 
> test, which failed at parse_parameters. 
> > 
> > My issue is solved using the 
> vector.push_back(new ParsedFunction) approach. 
> My attempt at the resize approach isn't working; but push_back is fine. 
> > 
> > Related test code is here: 
> https://github.com/alexanderzimmerman/nsb-pcm/tree/bugs/tests 
> > ctest passes all tests except for issue_10_resize.cc. I'm guessing that 
> I have the syntax wrong somewhere. 
> > 
> > Thanks for the help! 
> > 
> > 
> > On Wednesday, March 22, 2017 at 10:01:21 PM UTC+1, Timo Heister wrote: 
> > Your call to resize() will create 4 shared_ptrs, but they are pointing 
> > to nothing (NULL) because you are never allocating any objects and 
> > assigning them. 
> > 
> > Think of this example: 
> > std::vector v; 
> > v.resize(4); 
> > now v[0] is a pointer to an int, but it is NULL unless you do something 
> like 
> > v[0] = new int; 
> > 
> > 
> > 
> > On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman 
> >  wrote: 
> > > Also for the record, I verified that the test passes if I use a 
> > > std::vector without resizing: 
> > > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_blob_bugs_tests_bug-5F10-5Fpass.cc=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=v1-30ZnlLX9dscEMGIPAxToOfyXrgOcTjUUS54eVdJA=
>  
> > > 
> > > 
> > > 
> > > On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman 
> wrote: 
> > >> 
> > >> Luca, 
> > >> 
> > >> Thanks for the idea. Conceptually I don't understand how a shared_ptr 
> > >> solves my problem. I can resize 
> > >> std::vector>; 
> but 
> > >> all of the shared pointers are empty. I imagine that they are 
> supposed to 
> > >> point to ParsedFunction 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  
> > >> 
> > >> #include  
> > >> #include  
> > >> 
> > >> int main(int /*argc*/, char** /*argv*/) 
> > >> { 
> > >> const unsigned int dim = 2; 
> > >> const unsigned int function_count = 4; 
> > >> 
> > >> 
> std::vector> 
> > >> 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)); 
> > >> { 
> > >> 

Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-23 Thread luca.heltai
Resizing is fine. It is the equality that won’t work:

function_pointers[f] = 
 std::shared_ptr(new 
dealii::Functions::ParsedFunction()));

is the correct way to do it. 

L.


> On 23 Mar 2017, at 15:09, Alex Zimmerman  wrote:
> 
> Also for the record, here's a copy of issue_10_push_back.cc from that 
> repository, which is the example of how to solve my issue:
> 
> #include 
> 
> #include 
> #include  
> 
> int main(int /*argc*/, char** /*argv*/)
> {
> const unsigned int dim = 2;
> const unsigned int function_count = 4;
> 
> std::vector>
> function_pointers;
> 
> dealii::ParameterHandler prm;
> dealii::Point point;
> double value;
> 
> for (unsigned int f = 0; f < function_count; ++f)
> {
> function_pointers.push_back(
> std::shared_ptr(new 
> dealii::Functions::ParsedFunction()));
> 
> prm.enter_subsection("parsed_function_"+std::to_string(f));
> {
> function_pointers[f]->declare_parameters(prm);
> function_pointers[f]->parse_parameters(prm);
> }
> prm.leave_subsection();
> 
> function_pointers[f]->value(point, value);
> 
> std::cout << "f(" << point << ") = " << value << std::endl;
> }
> 
> return 0;
> }
> 
> 
> On Thursday, March 23, 2017 at 3:05:53 PM UTC+1, Alex Zimmerman wrote:
> Timo, thanks for the extra clarification. As I mentioned in my reply to Luca, 
> I don't understand why declare_parameters appeared to succeed in my test, 
> which failed at parse_parameters.
> 
> My issue is solved using the vector.push_back(new 
> ParsedFunction) approach. My attempt at the resize approach isn't working; 
> but push_back is fine. 
> 
> Related test code is here: 
> https://github.com/alexanderzimmerman/nsb-pcm/tree/bugs/tests
> ctest passes all tests except for issue_10_resize.cc. I'm guessing that I 
> have the syntax wrong somewhere.
> 
> Thanks for the help!
> 
> 
> On Wednesday, March 22, 2017 at 10:01:21 PM UTC+1, Timo Heister wrote:
> Your call to resize() will create 4 shared_ptrs, but they are pointing 
> to nothing (NULL) because you are never allocating any objects and 
> assigning them. 
> 
> Think of this example: 
> std::vector v; 
> v.resize(4); 
> now v[0] is a pointer to an int, but it is NULL unless you do something like 
> v[0] = new int; 
> 
> 
> 
> On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman 
>  wrote: 
> > Also for the record, I verified that the test passes if I use a 
> > std::vector without resizing: 
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_blob_bugs_tests_bug-5F10-5Fpass.cc=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=v1-30ZnlLX9dscEMGIPAxToOfyXrgOcTjUUS54eVdJA=
> >  
> > 
> > 
> > 
> > On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman wrote: 
> >> 
> >> Luca, 
> >> 
> >> Thanks for the idea. Conceptually I don't understand how a shared_ptr 
> >> solves my problem. I can resize 
> >> std::vector>; but 
> >> all of the shared pointers are empty. I imagine that they are supposed to 
> >> point to ParsedFunction 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  
> >> 
> >> #include  
> >> #include  
> >> 
> >> int main(int /*argc*/, char** /*argv*/) 
> >> { 
> >> const unsigned int dim = 2; 
> >> const unsigned int function_count = 4; 
> >> 
> >> std::vector> 
> >> 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 

Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-23 Thread Alex Zimmerman
Timo, thanks for the extra clarification. As I mentioned in my reply to 
Luca, I don't understand why declare_parameters appeared to succeed in my 
test, which failed at parse_parameters.

My issue is solved using the 
vector.push_back(new ParsedFunction) approach. 
My attempt at the resize approach isn't working; but push_back is fine. 

Related test code is here: 
https://github.com/alexanderzimmerman/nsb-pcm/tree/bugs/tests
ctest passes all tests except for issue_10_resize.cc 
.
 
I'm guessing that I have the syntax wrong somewhere.

Thanks for the help!


On Wednesday, March 22, 2017 at 10:01:21 PM UTC+1, Timo Heister wrote:
>
> Your call to resize() will create 4 shared_ptrs, but they are pointing 
> to nothing (NULL) because you are never allocating any objects and 
> assigning them. 
>
> Think of this example: 
> std::vector v; 
> v.resize(4); 
> now v[0] is a pointer to an int, but it is NULL unless you do something 
> like 
> v[0] = new int; 
>
>
>
> On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman 
>  wrote: 
> > Also for the record, I verified that the test passes if I use a 
> > std::vector without resizing: 
> > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_blob_bugs_tests_bug-5F10-5Fpass.cc=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=v1-30ZnlLX9dscEMGIPAxToOfyXrgOcTjUUS54eVdJA=
>  
> > 
> > 
> > 
> > On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman wrote: 
> >> 
> >> Luca, 
> >> 
> >> Thanks for the idea. Conceptually I don't understand how a shared_ptr 
> >> solves my problem. I can resize 
> >> std::vector>; 
> but 
> >> all of the shared pointers are empty. I imagine that they are supposed 
> to 
> >> point to ParsedFunction 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  
> >> 
> >> #include  
> >> #include  
> >> 
> >> int main(int /*argc*/, char** /*argv*/) 
> >> { 
> >> const unsigned int dim = 2; 
> >> const unsigned int function_count = 4; 
> >> 
> >> 
> std::vector> 
> >> 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 > 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(…) ); 
> >>> 
> >>> then 
> >>> 
> >>> v[i]->value(…) 
> >>> 
> >>> would work. 
> >>> 
> >>> 
> >>> > On 22 Mar 2017, at 16:31, Alex Zimmerman  
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_issues_10=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=a-21yeSa2EGcnF7p79Efq_xBzJ8qavKiAtJHROzgbX0=
>  
>  . Here's a copy of 
> >>> > the text from my issue, which pretty much explains 

Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-22 Thread Timo Heister
Your call to resize() will create 4 shared_ptrs, but they are pointing
to nothing (NULL) because you are never allocating any objects and
assigning them.

Think of this example:
std::vector v;
v.resize(4);
now v[0] is a pointer to an int, but it is NULL unless you do something like
v[0] = new int;



On Wed, Mar 22, 2017 at 3:09 PM, Alex Zimmerman
 wrote:
> Also for the record, I verified that the test passes if I use a
> std::vector without resizing:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_blob_bugs_tests_bug-5F10-5Fpass.cc=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=v1-30ZnlLX9dscEMGIPAxToOfyXrgOcTjUUS54eVdJA=
>  
>
>
>
> On Wednesday, March 22, 2017 at 7:17:25 PM UTC+1, Alex Zimmerman wrote:
>>
>> Luca,
>>
>> Thanks for the idea. Conceptually I don't understand how a shared_ptr
>> solves my problem. I can resize
>> std::vector>; but
>> all of the shared pointers are empty. I imagine that they are supposed to
>> point to ParsedFunction 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 
>>
>> #include 
>> #include 
>>
>> int main(int /*argc*/, char** /*argv*/)
>> {
>> const unsigned int dim = 2;
>> const unsigned int function_count = 4;
>>
>> std::vector>
>> 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 > 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(…) );
>>>
>>> then
>>>
>>> v[i]->value(…)
>>>
>>> would work.
>>>
>>>
>>> > On 22 Mar 2017, at 16:31, Alex Zimmerman  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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_alexanderzimmerman_nsb-2Dpcm_issues_10=DwIFaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=bMNkhuzVlxuFjrw_sjeYQVtM1sMLS6wmKIkP9ILH7d4=a-21yeSa2EGcnF7p79Efq_xBzJ8qavKiAtJHROzgbX0=
>>> >   . 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 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 

Re: [deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-22 Thread luca.heltai
Hi Alex, 

I’d use a vector of 

std::vector > 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_pointervalue(…)

would work.


> On 22 Mar 2017, at 16:31, Alex Zimmerman  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 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 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 Allocator, ETS_key_type>::unconstruct_locals() [with T = 
> std::vectormu::Parser; Allocator = 
> tbb::cache_aligned_allocator; 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 dealii+unsubscr...@googlegroups.com.
> 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 dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] How can I resize a std::vector<Functions::ParsedFunction>?

2017-03-22 Thread Alex Zimmerman
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 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::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::unconstruct_locals() [with T = 
std::vectormu::Parser; Allocator = 
tbb::cache_aligned_allocator; 
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 dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.