from:"Alex Zimmerman"

Re: [deal.II] Catching exception for find_active_cell_around_point?

2016-08-17 Thread Alex Zimmerman

I'm new to deal.II and I'm having a similar problem. I'm trying to extend 
the FEFieldFunction class with an extrapolated_value method that handles 
this exception.

Here's the relevant method:

template
double ExtrapolatedField::
   extrapolated_value(const Point ,
  const unsigned int) {
   double val;
   try {
   val = this->value(point);
   }
   catch (GridTools::ExcPointNotFound) {
  val = this->value(this->get_nearest_boundary_vertex(point));
   }
   return val;
}

It appears to me that the exception isn't being caught by my try-catch 
construct. The program aborts with the error:

Exception on processing:

An error occurred in line <1411> of file 
 in function
std::pair::active_cell_iterator, 
dealii::Point > dealii::GridTools::find_active_cell_around_point(const 
dealii::Mapping&, const MeshType&, const 
dealii::Point&) [with int dim = 2; MeshType = dealii::DoFHandler; 
int spacedim = 2; typename MeshType::active_cell_iterator = 
dealii::TriaActiveIterator, 
false> >]
The violated condition was:
best_cell.first.state() == IteratorState::valid
The name and call sequence of the exception was:
ExcPointNotFound(p)
Additional Information:
The point <0.487084 -0.116491> could not be found inside any of the 
subcells of a coarse grid cell.

Aborting!

After digging through the source code and documentation a bit, I was 
worried that this is the expected behavior of AssertThrow and that I could 
not suppress the abort signal. But this mailing this thread gives me hope.

Any advice?

Thanks,

Alex

On Tuesday, January 21, 2014 at 5:29:37 PM UTC+1, Timo Heister wrote:
>
> > I'm using 8.0.0. 
> > Should I upgrade? 
>
> 8.1.0 has many bugfixes and new features over 8.0.0 and it fixes your 
> problem, so that kind of makes sense. 
>
> -- 
> Timo Heister 
> http://www.math.clemson.edu/~heister/ 
>

-- 
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.

Re: [deal.II] Catching exception for find_active_cell_around_point?

2016-08-17 Thread Alex Zimmerman

That was indeed my problem. Silly mistake. This is why we use IDE's before 
posting to the mailing list. Also an FYI for anyone who stumbles upon this 
conversation with myself: I extended Function instead, adding a 
FEFieldFunction as a member.


On Wednesday, August 17, 2016 at 2:08:57 PM UTC+2, Alex Zimmerman wrote:
>
> I just stepped through my program with qtcreator and I found a mistake 
> that undermines my question. I thought I was using this extrapolated_value 
> method, but I was still using the parent class's value method. I imagine 
> that this will work once I fix that mistake. I'll update this thread if I 
> make progress :)
>
> On Wednesday, August 17, 2016 at 12:18:30 PM UTC+2, Alex Zimmerman wrote:
>>
>> I'm new to deal.II and I'm having a similar problem. I'm trying to extend 
>> the FEFieldFunction class with an extrapolated_value method that handles 
>> this exception.
>>
>> Here's the relevant method:
>>
>> template
>> double ExtrapolatedField<dim,DoFHandlerType,VectorType>::
>>extrapolated_value(const Point ,
>>   const unsigned int) {
>>double val;
>>try {
>>val = this->value(point);
>>}
>>catch (GridTools::ExcPointNotFound) {
>>   val = this->value(this->get_nearest_boundary_vertex(point));
>>}
>>return val;
>> }
>>
>>
>> It appears to me that the exception isn't being caught by my try-catch 
>> construct. The program aborts with the error:
>>
>> 
>> Exception on processing:
>>
>> 
>> An error occurred in line <1411> of file 
>>  in function
>> std::pair::active_cell_iterator, 
>> dealii::Point > dealii::GridTools::find_active_cell_around_point(const 
>> dealii::Mapping<dim, spacedim>&, const MeshType<dim, spacedim>&, const 
>> dealii::Point&) [with int dim = 2; MeshType = dealii::DoFHandler; 
>> int spacedim = 2; typename MeshType<dim, spacedim>::active_cell_iterator = 
>> dealii::TriaActiveIterator<dealii::DoFCellAccessor<dealii::DoFHandler<2>, 
>> false> >]
>> The violated condition was:
>> best_cell.first.state() == IteratorState::valid
>> The name and call sequence of the exception was:
>> ExcPointNotFound(p)
>> Additional Information:
>> The point <0.487084 -0.116491> could not be found inside any of the 
>> subcells of a coarse grid cell.
>> 
>>
>> Aborting!
>> 
>>
>>
>> After digging through the source code and documentation a bit, I was 
>> worried that this is the expected behavior of AssertThrow and that I could 
>> not suppress the abort signal. But this mailing this thread gives me hope.
>>
>> Any advice?
>>
>> Thanks,
>>
>> Alex
>>
>> On Tuesday, January 21, 2014 at 5:29:37 PM UTC+1, Timo Heister wrote:
>>>
>>> > I'm using 8.0.0. 
>>> > Should I upgrade? 
>>>
>>> 8.1.0 has many bugfixes and new features over 8.0.0 and it fixes your 
>>> problem, so that kind of makes sense. 
>>>
>>> -- 
>>> Timo Heister 
>>> http://www.math.clemson.edu/~heister/ 
>>>
>>

-- 
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] Re: Failing to set up simple test configuration

2016-09-07 Thread Alex Zimmerman

The recent Windows 10 "Anniversary Update" included an entire built-in 
Ubuntu (14.04) subsystem: 
https://msdn.microsoft.com/en-us/commandline/wsl/about

I've built a few different versions of deal.II on this system, including 
the candi build with Trilinos, p4est, etc. This was all painless, so 
definitely try it out if you can use the latest version of Windows.

It's actually called "Bash on Ubuntu on Windows", and it's marketed as just 
being a bash prompt useful for command line tools; but it appears much more 
capable than that. Also it can read/write from/to the entire Windows C: 
drive, which is the "/mnt/c" path in my question. This has been useful so 
that I can use Notepad++ and Paraview from Windows. "Bash on Ubuntu on 
Windows" currently isn't very good at forwarding graphics. Even gedit 
doesn't forward very well. There might be some low level magic that 
Microsoft has performed to make all of this work. Presently it appears that 
my issue is related to MS-DOS not allowing my ctest to do some inline file 
editing on my C: drive. But this is indeed to first issue I've had, so the 
system looks quite promising.

After some brief Googling, I think I might even be able to fix this issue 
if I could find where the code is that is causing the error "Can't do 
inplace edit on 
/mnt/c/Users/Alexander/UbuntuShared/dimice-heat-dealii/build/tests/cylinder.debug/output:
 
No such file or directory." Unfortunately I'm completely unfamiliar with 
the test system and I have not a clue.


On Wednesday, September 7, 2016 at 10:29:54 AM UTC+2, Jean-Paul Pelteret 
wrote:
>
> Great, glad that you sorted it out!
>
> By the way, there's recently been a discussion on GitHub 
> <https://github.com/dealii/dealii/issues/3060> related to running deal.II 
> on windows. Its interesting to hear that you've got it running on Windows 
> 10. Out of curiosity, how have you configured deal.II? Do you link it 
> against any external libraries?
>
> On Wednesday, September 7, 2016 at 10:07:06 AM UTC+2, Alex Zimmerman wrote:
>>
>> This might be a problem with my file system. I've been successfully using 
>> the Ubuntu subsystem on Windows 10 for the past few weeks, and that's where 
>> the odd "/mnt/c/Users..." path comes from in my question.
>>
>> I just tried this again at my home directory, and it worked. I thought I 
>> had tried running the test on my user project in my home directory, but I'm 
>> fairly sure I never tried this simple step-1 example there.
>>
>> So now this is working:
>>
>> $ ctest
>>
>>  
>>
>> Test project /home/zimmerman/temp/step-1/build
>>> Start 1: tests/my_test.debug
>>> 1/1 Test #1: tests/my_test.debug ..   Passed5.51 sec
>>> 100% tests passed, 0 tests failed out of 1
>>> Total Test time (real) =   5.52 sec
>>
>>
>>
>> One of these days I'll ask a question that I don't answer myself a few 
>> minutes later :)
>>
>>
>> On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex Zimmerman wrote:
>>>
>>> Maybe this is a bug, but I think it's more likely that I'm doing 
>>> something wrong here.
>>>
>>> I had tried to set up a test for my user code following the instructions 
>>> at https://www.dealii.org/developer/users/testsuite.html. This failed; 
>>> so I attempted to set this up with step-1, using the exact CMakeLists from 
>>> the "simple configuration" example and following the same steps to produce 
>>> the parameter file, configure the test, and run the test.
>>>
>>> Originally I was on my own branch of deal.II-8.5.0-pre; but now I've 
>>> reproduced the same problem with the latest release, 8.4.2.
>>>
>>> I configure, build, and run the test 
>>>
>>> $ cd step-1
>>> $ mkdir build
>>> $ cd build/
>>> $ cmake ..
>>>
>>>  
>>>
>>> -- Using the deal.II-8.4.2 installation found at 
>>>> /home/zimmerman/Installed/dealii-8.4.2
>>>> -- Include macro 
>>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_add_test.cmake
>>>> -- Include macro 
>>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_initialize_cached_variables.cmake
>>>> -- Include macro 
>>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_invoke_autopilot.cmake
>>>> -- Include macro 
>>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_pickup_tests.cmake
>>>> -- Include macro 
>>>> /home/zimmerman/Installed/

[deal.II] Re: Failing to set up simple test configuration

2016-09-07 Thread Alex Zimmerman

Actually numdiff was already installed; I think that error was referring to 
the file simply not existing. See my latest reply. Thanks for your time!

On Wednesday, September 7, 2016 at 10:05:38 AM UTC+2, Jean-Paul Pelteret 
wrote:
>
> Hi Alex,
>
> numdiff: output: No such file or directory
>>
> /usr/bin/diff: output: No such file or directory
>>
>
> It appears that you might be missing some of the programs necessary to 
> check your test's output against the "blessed" result. Can you you check 
> that you have numdiff and diff installed and in path?
>
> Regards,
> J-P
>
> On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex Zimmerman wrote:
>>
>> Maybe this is a bug, but I think it's more likely that I'm doing 
>> something wrong here.
>>
>> I had tried to set up a test for my user code following the instructions 
>> at https://www.dealii.org/developer/users/testsuite.html. This failed; 
>> so I attempted to set this up with step-1, using the exact CMakeLists from 
>> the "simple configuration" example and following the same steps to produce 
>> the parameter file, configure the test, and run the test.
>>
>> Originally I was on my own branch of deal.II-8.5.0-pre; but now I've 
>> reproduced the same problem with the latest release, 8.4.2.
>>
>> I configure, build, and run the test 
>>
>> $ cd step-1
>> $ mkdir build
>> $ cd build/
>> $ cmake ..
>>
>>  
>>
>> -- Using the deal.II-8.4.2 installation found at 
>>> /home/zimmerman/Installed/dealii-8.4.2
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_add_test.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_initialize_cached_variables.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_invoke_autopilot.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_pickup_tests.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_query_git_information.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_setup_target.cmake
>>> -- The C compiler identification is GNU 4.8.4
>>> -- The CXX compiler identification is GNU 4.8.4
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Autopilot invoked
>>> ###
>>> #
>>> #  Project  step-1  set up with  deal.II-8.4.2  found at
>>> #  /home/zimmerman/Installed/dealii-8.4.2
>>> #
>>> #  CMAKE_BUILD_TYPE:  Debug
>>> #
>>> #  You can now run
>>> #   $ make- to compile and link the program
>>> #   $ make run- to (compile, link and) run the program
>>> #
>>> #   $ make debug  - to switch the build type to 'Debug'
>>> #   $ make release- to switch the build type to 'Release'
>>> #
>>> #   $ make edit_cache - to change (cached) configuration 
>>> variables
>>> #   and rerun the configure and generate 
>>> phases of CMake
>>> #
>>> #   $ make strip_comments - to strip the source files in this
>>> #   directory off the documentation comments
>>> #   $ make clean  - to remove the generated executable as 
>>> well as
>>> #   all intermediate compilation files
>>> #   $ make runclean   - to remove all output generated by the 
>>> program
>>> #   $ make distclean  - to clean the directory from _all_ 
>>> generated
>>> #   files (includes clean, runclean and the 
>>> removal
>>> #   of the generated build system)
>>> #   $ make info   - to view this message again
>>> #
>>> #  Have a nice day!
>>> #
>>> ###
>>> -- Found Perl: /usr/bin/perl (found version "5.18.2")
>>>

[deal.II] Re: Failing to set up simple test configuration

2016-09-07 Thread Alex Zimmerman

This might be a problem with my file system. I've been successfully using 
the Ubuntu subsystem on Windows 10 for the past few weeks, and that's where 
the odd "/mnt/c/Users..." path comes from in my question.

I just tried this again at my home directory, and it worked. I thought I 
had tried running the test on my user project in my home directory, but I'm 
fairly sure I never tried this simple step-1 example there.

So now this is working:

$ ctest

 

Test project /home/zimmerman/temp/step-1/build
> Start 1: tests/my_test.debug
> 1/1 Test #1: tests/my_test.debug ..   Passed5.51 sec
> 100% tests passed, 0 tests failed out of 1
> Total Test time (real) =   5.52 sec



One of these days I'll ask a question that I don't answer myself a few 
minutes later :)


On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex Zimmerman wrote:
>
> Maybe this is a bug, but I think it's more likely that I'm doing something 
> wrong here.
>
> I had tried to set up a test for my user code following the instructions 
> at https://www.dealii.org/developer/users/testsuite.html. This failed; so 
> I attempted to set this up with step-1, using the exact CMakeLists from the 
> "simple configuration" example and following the same steps to produce the 
> parameter file, configure the test, and run the test.
>
> Originally I was on my own branch of deal.II-8.5.0-pre; but now I've 
> reproduced the same problem with the latest release, 8.4.2.
>
> I configure, build, and run the test 
>
> $ cd step-1
> $ mkdir build
> $ cd build/
> $ cmake ..
>
>  
>
> -- Using the deal.II-8.4.2 installation found at 
>> /home/zimmerman/Installed/dealii-8.4.2
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_add_test.cmake
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_initialize_cached_variables.cmake
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_invoke_autopilot.cmake
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_pickup_tests.cmake
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_query_git_information.cmake
>> -- Include macro 
>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_setup_target.cmake
>> -- The C compiler identification is GNU 4.8.4
>> -- The CXX compiler identification is GNU 4.8.4
>> -- Check for working C compiler: /usr/bin/cc
>> -- Check for working C compiler: /usr/bin/cc -- works
>> -- Detecting C compiler ABI info
>> -- Detecting C compiler ABI info - done
>> -- Check for working CXX compiler: /usr/bin/c++
>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>> -- Detecting CXX compiler ABI info
>> -- Detecting CXX compiler ABI info - done
>> -- Autopilot invoked
>> ###
>> #
>> #  Project  step-1  set up with  deal.II-8.4.2  found at
>> #  /home/zimmerman/Installed/dealii-8.4.2
>> #
>> #  CMAKE_BUILD_TYPE:  Debug
>> #
>> #  You can now run
>> #   $ make- to compile and link the program
>> #   $ make run- to (compile, link and) run the program
>> #
>> #   $ make debug  - to switch the build type to 'Debug'
>> #   $ make release- to switch the build type to 'Release'
>> #
>> #   $ make edit_cache - to change (cached) configuration variables
>> #   and rerun the configure and generate 
>> phases of CMake
>> #
>> #   $ make strip_comments - to strip the source files in this
>> #   directory off the documentation comments
>> #   $ make clean  - to remove the generated executable as 
>> well as
>> #   all intermediate compilation files
>> #   $ make runclean   - to remove all output generated by the 
>> program
>> #   $ make distclean  - to clean the directory from _all_ 
>> generated
>> #   files (includes clean, runclean and the 
>> removal
>> #   of the generated build system)
>> #   $ make info   - to view this message again
>> #
>> #  Have a nice day!
>> #
>> ###
>> -- Found Perl: /usr/bin/perl (found version "5.18.2")
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: 
>> /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>> zimmerma

[deal.II] Re: Failing to set up simple test configuration

2016-09-07 Thread Alex Zimmerman

I should add that I'm still quite curious as to why this problem occurs; 
but I don't expect anyone to want to spend time debugging an "Ubuntu on 
Windows" problem. This is the first issue I've had with the file system. 
Other outputs write perfectly fine.


On Wednesday, September 7, 2016 at 10:07:06 AM UTC+2, Alex Zimmerman wrote:
>
> This might be a problem with my file system. I've been successfully using 
> the Ubuntu subsystem on Windows 10 for the past few weeks, and that's where 
> the odd "/mnt/c/Users..." path comes from in my question.
>
> I just tried this again at my home directory, and it worked. I thought I 
> had tried running the test on my user project in my home directory, but I'm 
> fairly sure I never tried this simple step-1 example there.
>
> So now this is working:
>
> $ ctest
>
>  
>
> Test project /home/zimmerman/temp/step-1/build
>> Start 1: tests/my_test.debug
>> 1/1 Test #1: tests/my_test.debug ..   Passed5.51 sec
>> 100% tests passed, 0 tests failed out of 1
>> Total Test time (real) =   5.52 sec
>
>
>
> One of these days I'll ask a question that I don't answer myself a few 
> minutes later :)
>
>
> On Wednesday, September 7, 2016 at 9:57:33 AM UTC+2, Alex Zimmerman wrote:
>>
>> Maybe this is a bug, but I think it's more likely that I'm doing 
>> something wrong here.
>>
>> I had tried to set up a test for my user code following the instructions 
>> at https://www.dealii.org/developer/users/testsuite.html. This failed; 
>> so I attempted to set this up with step-1, using the exact CMakeLists from 
>> the "simple configuration" example and following the same steps to produce 
>> the parameter file, configure the test, and run the test.
>>
>> Originally I was on my own branch of deal.II-8.5.0-pre; but now I've 
>> reproduced the same problem with the latest release, 8.4.2.
>>
>> I configure, build, and run the test 
>>
>> $ cd step-1
>> $ mkdir build
>> $ cd build/
>> $ cmake ..
>>
>>  
>>
>> -- Using the deal.II-8.4.2 installation found at 
>>> /home/zimmerman/Installed/dealii-8.4.2
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_add_test.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_initialize_cached_variables.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_invoke_autopilot.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_pickup_tests.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_query_git_information.cmake
>>> -- Include macro 
>>> /home/zimmerman/Installed/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_setup_target.cmake
>>> -- The C compiler identification is GNU 4.8.4
>>> -- The CXX compiler identification is GNU 4.8.4
>>> -- Check for working C compiler: /usr/bin/cc
>>> -- Check for working C compiler: /usr/bin/cc -- works
>>> -- Detecting C compiler ABI info
>>> -- Detecting C compiler ABI info - done
>>> -- Check for working CXX compiler: /usr/bin/c++
>>> -- Check for working CXX compiler: /usr/bin/c++ -- works
>>> -- Detecting CXX compiler ABI info
>>> -- Detecting CXX compiler ABI info - done
>>> -- Autopilot invoked
>>> ###
>>> #
>>> #  Project  step-1  set up with  deal.II-8.4.2  found at
>>> #  /home/zimmerman/Installed/dealii-8.4.2
>>> #
>>> #  CMAKE_BUILD_TYPE:  Debug
>>> #
>>> #  You can now run
>>> #   $ make- to compile and link the program
>>> #   $ make run- to (compile, link and) run the program
>>> #
>>> #   $ make debug  - to switch the build type to 'Debug'
>>> #   $ make release- to switch the build type to 'Release'
>>> #
>>> #   $ make edit_cache - to change (cached) configuration 
>>> variables
>>> #   and rerun the configure and generate 
>>> phases of CMake
>>> #
>>> #   $ make strip_comments - to strip the source files in this
>>> #   directory off the documentation comments
>>> #   $ make clean  - to remove the generated executable as 
>>> well as
>>> #   all intermediate comp

Re: [deal.II] Why is this asserted to be impossible?

2016-09-18 Thread Alex Zimmerman

I question all of the asserts in this 
file: 
https://github.com/dealii/dealii/blob/master/source/numerics/vector_tools_rhs.cc

My particular case is the one on line 36, for dim = 1 and spacedim = 1.

Thanks for looking into this.


On Sunday, September 18, 2016 at 2:42:01 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 09/17/2016 05:20 AM, Alex Zimmerman wrote: 
> > 
> > Not understanding why this is impossible, I began digging through the 
> code a 
> > bit and thought I would write my own 1D implementation. I noticed that 
> the 
> > code in the existing template should work correctly without any changes. 
> So 
> > instead I simply copied and renamed the template, without the 
> implementation 
> > asserting impossibility in 1D ( Assert(false, ExcImpossibleInDim(1)); ). 
> My 
> > first test ran exactly as expected. 
> > 
> > deal.II often asserts that something doesn't make sense or is impossible 
> in a 
> > certain dimension. Sometimes I agree and sometimes I don't. This is the 
> first 
> > time that it's just seemed completely wrong to me. What am I missing? 
>
> Quite possibly nothing -- we may simply be wrong. Can you point out the 
> file 
> and line where the offending Assert is located? 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> 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 dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[deal.II] Re: Untraceable "not implemented" error in GDB

2016-09-16 Thread Alex Zimmerman

Yep that does it! Thanks for your patience :)

On Friday, September 16, 2016 at 7:28:41 PM UTC+2, Bruno Turcksin wrote:
>
> Alex,
>
> before the run command, you need to use: catch throw 
>
> Best,
>
> Bruno
>
> On Friday, September 16, 2016 at 1:21:41 PM UTC-4, Alex Zimmerman wrote:
>>
>> A couple of times now I have encountered GDB output similar to my 
>> attached snapshot.
>>
>> The previous time I had only made a very small change to my code, so it 
>> was easy enough for me to figure out on my own. Presently I'm trying to run 
>> a 1D version of my code for the first time. So far I've only ran 2D 
>> problems, though I have been attempting to employ the dimension independent 
>> programming found throughout the library.
>>
>> So I imagine that there is some templated method I'm using which simply 
>> has not been implemented in 1D. Any tips on how to quickly narrow down 
>> which specific method(s) is/are throwing this exception? Is it extremely 
>> odd that this exception doesn't point me to the source code?
>>
>> I'm on Ubuntu 14.04 and using a debug build of a 8.5.0-pre version of 
>> deal.II at commit 0752c81b84c7f9c737ef62ac09932853bb976f8d
>>
>> As shown in the snapshot, GDB has consistently been throwing a couple of 
>> warnings. I always get those warnings and this is only the second time I've 
>> had an untraceable error, both of which are related to the "not 
>> implemented" cases; so I'm guessing that it's unrelated, but I could be 
>> entirely wrong about that.
>>
>> Any ideas? Thanks!
>>
>

-- 
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] Why is this asserted to be impossible?

2016-09-17 Thread Alex Zimmerman

I have a code that is an extension of step-26 with non-homogeneous Neumann 
boundary conditions and zero forcing function, among other changes. Until 
recently I had only actually run the code in 2D, though I have been 
continuing the "dimension independent" programming.

Yesterday I tried running a simple 1D case for the first time. I was 
already using VectorTools::create_boundary_rhs to apply the Neumann 
boundary conditions. Unfortunately I discovered that the 1D implementations 
of create_boundary_rhs all assert that this is an impossible operation in 
1D.

Not understanding why this is impossible, I began digging through the code 
a bit and thought I would write my own 1D implementation. I noticed that 
the code in the existing template should work correctly without any 
changes. So instead I simply copied and renamed the template, without the 
implementation asserting impossibility in 1D ( Assert (false, 
ExcImpossibleInDim(1)); ). My first test ran exactly as expected.

deal.II often asserts that something doesn't make sense or is impossible in 
a certain dimension. Sometimes I agree and sometimes I don't. This is the 
first time that it's just seemed completely wrong to me. What am I missing?

-- 
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.

Re: [deal.II] Re: Failing to set up simple test configuration

2016-09-16 Thread Alex Zimmerman

Wolfgang, thanks for pointing me to this part of the code. I'm not sure 
when I'll try to fix the problem, because it was very simple to just only 
ever run ctest on the Linux filesystem, completely circumventing it. I'll 
make sure to post an update if I ever fix this so that I can run ctest on 
the Windows filesystem (from the bash prompt).

On Wednesday, September 7, 2016 at 10:36:21 PM UTC+2, Wolfgang Bangerth 
wrote:
>
> On 09/07/2016 06:56 AM, Alex Zimmerman wrote: 
> > 
> > After some brief Googling, I think I might even be able to fix this 
> issue if I 
> > could find where the code is that is causing the error "Can't do inplace 
> edit 
> > on 
> > 
> /mnt/c/Users/Alexander/UbuntuShared/dimice-heat-dealii/build/tests/cylinder.debug/output:
>  
>
> > No such file or directory." Unfortunately I'm completely unfamiliar with 
> the 
> > test system and I have not a clue. 
>
> This happens in cmake/macros/macro_deal_ii_add_test.cmake, around line 
> 240: 
>
>ADD_CUSTOM_COMMAND(OUTPUT ${_test_directory}/output 
>  COMMAND sh 
> ${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/run_test.sh 
>run "${_test_full}" "${_run_command}" "${_test_diff}" 
>"${DIFF_EXECUTABLE}" "${_comparison_file}" 
>  COMMAND ${PERL_EXECUTABLE} 
>-pi ${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/
> normalize.pl 
>${_test_directory}/output 
>  WORKING_DIRECTORY 
>${_test_directory} 
>  DEPENDS 
>${_target} 
>${DEAL_II_PATH}/${DEAL_II_SHARE_RELDIR}/scripts/normalize.pl 
>  VERBATIM 
>  ) 
>
> We here call "perl -pi  ". 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> 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 dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: Failing to set up simple test configuration

2016-09-16 Thread Alex Zimmerman

Timo, when I looked into this before posting my question, it seemed to be a 
pretty clear issue with the perl command not working on the Windows 
filesystem. Per my recent reply to Wolfgang, I have moved forward with a 
simple work-around (which simply does not involve running ctest on the 
Windows file system). I imagine at some point in the not-so-distant future 
I'll be interested in fixing this. Of course please do let me know if 
you're interested and want to to reproduce the log for the group's purposes.

Thanks.

On Wednesday, September 7, 2016 at 6:44:09 PM UTC+2, Timo Heister wrote:
>
> Hey Alex, 
>
> I am not surprised you are running into issues, because you are the 
> first one to try "ubuntu on windows" to compile deal.II with (at least 
> as far as I know). 
>
> It could be a permission problem that you are running into, who knows. 
> Would you mind sharing you deal.II detailed.log? 
>
> On Wed, Sep 7, 2016 at 9:32 AM, Jean-Paul Pelteret <jppel...@gmail.com 
> > wrote: 
> > Hi Alex, 
> > 
> > Great, many thanks for your useful feedback. I've alerted the other 
> > developers to your comments so that they can be considered in the 
> discussion 
> > about getting deal.II to properly on windows. 
> > 
> > Cheers, 
> > J-P 
> > 
> > 
> > On Wednesday, September 7, 2016 at 2:56:10 PM UTC+2, Alex Zimmerman 
> wrote: 
> >> 
> >> The recent Windows 10 "Anniversary Update" included an entire built-in 
> >> Ubuntu (14.04) subsystem: 
> >> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__msdn.microsoft.com_en-2Dus_commandline_wsl_about=CwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=WDpmF-SkGP5uKyQ0vKXcggIG-I_RfG1fLlDteZEDQ_s=iVn3ecqjKuFP2DxDo7Q8ippSqeZvU8HaFT57rzJEvRQ=
>  
> >> 
> >> I've built a few different versions of deal.II on this system, 
> including 
> >> the candi build with Trilinos, p4est, etc. This was all painless, so 
> >> definitely try it out if you can use the latest version of Windows. 
> >> 
> >> It's actually called "Bash on Ubuntu on Windows", and it's marketed as 
> >> just being a bash prompt useful for command line tools; but it appears 
> much 
> >> more capable than that. Also it can read/write from/to the entire 
> Windows C: 
> >> drive, which is the "/mnt/c" path in my question. This has been useful 
> so 
> >> that I can use Notepad++ and Paraview from Windows. "Bash on Ubuntu on 
> >> Windows" currently isn't very good at forwarding graphics. Even gedit 
> >> doesn't forward very well. There might be some low level magic that 
> >> Microsoft has performed to make all of this work. Presently it appears 
> that 
> >> my issue is related to MS-DOS not allowing my ctest to do some inline 
> file 
> >> editing on my C: drive. But this is indeed to first issue I've had, so 
> the 
> >> system looks quite promising. 
> >> 
> >> After some brief Googling, I think I might even be able to fix this 
> issue 
> >> if I could find where the code is that is causing the error "Can't do 
> >> inplace edit on 
> >> 
> /mnt/c/Users/Alexander/UbuntuShared/dimice-heat-dealii/build/tests/cylinder.debug/output:
>  
>
> >> No such file or directory." Unfortunately I'm completely unfamiliar 
> with the 
> >> test system and I have not a clue. 
> >> 
> >> 
> >> On Wednesday, September 7, 2016 at 10:29:54 AM UTC+2, Jean-Paul 
> Pelteret 
> >> wrote: 
> >>> 
> >>> Great, glad that you sorted it out! 
> >>> 
> >>> By the way, there's recently been a discussion on GitHub related to 
> >>> running deal.II on windows. Its interesting to hear that you've got it 
> >>> running on Windows 10. Out of curiosity, how have you configured 
> deal.II? Do 
> >>> you link it against any external libraries? 
> >>> 
> >>> On Wednesday, September 7, 2016 at 10:07:06 AM UTC+2, Alex Zimmerman 
> >>> wrote: 
> >>>> 
> >>>> This might be a problem with my file system. I've been successfully 
> >>>> using the Ubuntu subsystem on Windows 10 for the past few weeks, and 
> that's 
> >>>> where the odd "/mnt/c/Users..." path comes from in my question. 
> >>>> 
> >>>> I just tried this again at my home directory, and it worked. I 
> thought I 
> >>>> had tried running the test on my user project in my home directory, 
> but I'm 
>

[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.

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<shared_ptr>.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 
<https://github.com/alexanderzimmerman/nsb-pcm/blob/bugs/tests/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<int*> 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 
> <zimmerma...@gmail.com > wrote: 
> > Also for the record, I verified that the test passes if I use a 
> > std::vector<dealii::Functions::ParsedFunction> 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<std::shared_ptr<dealii::Functions::ParsedFunction>>; 
> 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<std::shared_ptr<dealii::Functions::ParsedFunction>> 
> >> 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 > > 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(new 
> >>> ParsedFunction(…) ); 
> >>> 
> >>> then 
> >>> 
> >>> v[i]->value(…) 
> >>> 
&g

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

2017-04-05 Thread Alex Zimmerman

Thanks for the clarification, Jean-Paul. I'm glad to hear that my syntax is 
correct.

I am indeed using an extractor, e.g. here's a line from my code:
const Tensor<2, dim> gradv = fe_values[velocity].gradient(j, quad);

I'm having some trouble finding an example of the S[i][j] syntax in either 
tutorial. Part of step 44 has the following for the geometric stress 
contribution:
data.cell_matrix(i, j) += grad_Nx[i][component_i] * tau
 * grad_Nx[j][component_j] * JxW;

which is at least using the same operators to read the components; but it's 
not clear to me that this maps to the $S_{i,j}$ notation we discussed. It 
seems they have to do some work to map to the correct indices, i.e. with
const unsigned int component_i = fe.system_to_component_index 
<https://dealii.org/developer/doxygen/deal.II/classFiniteElement.html#a27220a135402b96c7e6eecbb04acda56>
(i).first;

For now I'm satisfied with having an experience user confirm that my syntax 
is correct; but I might want to formulate a test, unless a clear example 
already exists somewhere. I should be able to write something down for a 
simple PDE with a simple basis. I get the feeling that I'd just be testing 
a well established deal.II code behavior. Maybe I'm missing something 
obvious in the information you already provided.

I'm going to describe my specific problem a bit more in case there's an all 
around better way to do this: This is coming from the incompressible 
Navier-Stokes momentum equation with the term $(\mathbf{u} \cdot \nabla) 
\mathbf{u}$. The nonlinear variational form uses the operator 
$c(\mathbf{w};mathbf{z},mathbf{v} = \int{[(\mathbf{w} \cdot \nabla) 
\mathbf{z}] \cdot \mathbf{v} d\Omega}_\Omega = 
\sum{\sum{\int{w_j(\partial_j z_i)v_i d\Omega}_\Omega}_{j=1}^n}_{i=1}^n$

When I implement this with higher level library, FEniCS, I don't have to 
write the summation; but I think I have to write the summation in deal.II; 
hence I need to access $\partial_j z_i$, which I'm doing with the S[i][j] 
syntax that we discussed. I actually implement something similar to the 
integrand of this operator, for a given quadrature point and degree of 
freedom, with the lambda function:
auto c = [](
const Tensor<1, dim> _w,
const Tensor<2, dim> _gradz,
const Tensor<1, dim> _v)
{
double sum = 0.;

for (unsigned int i = 0; i < dim ; ++i)
{
for (unsigned int j = 0; j < dim; ++j)
{

sum += _w[j]*_gradz[i][j]*_v[i];

}
}

return sum;
};

Thanks for the help!

P.S. What's the best way to communicate math equations on the mailing list? 
I'm just typing what I think is roughly the correct LaTeX syntax, but this 
seems a bit clunky.

On Wednesday, April 5, 2017 at 3:04:04 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Dear Alex,
>
> What you've stated is correct. The tensor component $S_{ij}$ is exactly 
> component S[i][j] of a Tensor<2,dim> S if "S" represents $S_{ij} = 
> \partial v_{i} \partial x_{j}$.
>
> As for an example, both steps 18 
> <https://dealii.org/developer/doxygen/deal.II/step_18.html#TopLevelupdate_quadrature_point_history>
>  
> and 44 
> <https://dealii.org/developer/doxygen/deal.II/step_44.html#Solidupdate_qph_incremental>
>  
> both extract gradient of the vector-valued solution field. In step-18, the 
> gradient tensor is constructed manually after a the call to 
> fe_values.get_function_gradients 
> <https://dealii.org/developer/doxygen/deal.II/classFEValuesBase.html#a69c63f8be0311c8970253276ac7df138>
>  
> (incremental_displacement,
>  displacement_increment_grads);
> while in step-44 an extractor is used as well in order to produce $\Grad 
> \mathbf{u}$ (u representing the displacement) at each quadrature point 
> directly:
>   scratch.fe_values_ref[u_fe].get_function_gradients(scratch.
> solution_total,
> scratch.
> solution_grads_u_total);
>
> Depending on whether or not you use an extractor to perform this task, the 
> data structure in which the result is placed (here, 
> displacement_increment_grads 
> and scratch.solution_grads_u_total) is slightly different. When using an 
> extractor you will end up with the vector (each entry representing data at 
> a quadrature point) of rank-2 tensors because it is known that this is the 
> gradient of a vector field - this would be exactly "S" if the extractor 
> pertains to the velocity field. In contrast, the FEValues object knows 
> nothing about the solved fields if no extractor is used, so you'd have to 
> reconstruct "S" manually, in a similar way to that which is done in step-18.
>
> I hope that this helps clarify things a lit

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

2017-04-06 Thread Alex Zimmerman

Thanks for following up.

I don't think that 
double sum = v*gradz*w 

is equivalent to 
double sum = 0.; 
for (unsigned int i = 0; i < dim ; ++i)
{
for (unsigned int j = 0; j < dim; ++j)
{
sum += _w[j]*_gradz[i][j]*_v[i];
}
}

Most importantly, making the change definitely changes the behavior of my 
code; but I think this is explained by the term I wrote before which 
convects the velocity field, i.e. $[(\mathbf{w} \cdot \nabla) \mathbf{z}] 
\cdot \mathbf{v}$. The problem is how the $\nabla$ operator is grouped with 
$w$ on the left. The notation might be specific to the continuum mechanics 
community. First the dot product must be taken between the vector w and the 
gradient operator (which requires viewing the gradient operator as a 
vector), and then this result is multiplied by z, and then the dot product 
is taken between that result and v. Of course I'm doing this for the first 
time, so I could be misunderstanding something.

Later on I might want to implement this differently, maybe more like some 
of the tutorials you mentioned; but I'm trying to reproduce a result from a 
paper which uses this form. It's somewhat unique because it uses Newton's 
method to linearize the nonlinear variational form.

Now that I write this, I recall that the deal.II homepage News feed links 
to someone solving the stationary problem with Newton's method, step-57 
. This didn't 
show up when I was glancing through the tutorials recently. I'm going to 
see if that tutorial helps :)

On Wednesday, April 5, 2017 at 8:14:36 PM UTC+2, Jean-Paul Pelteret wrote:
>
> Hi Alex,
>>>
>>  
>
>> Thanks for the clarification, Jean-Paul. 
>>
>
> I'm sorry to say that you shouldn't be too quick in this instance to thank 
> me...
>  
>
>> I'm glad to hear that my syntax is correct.
>>
>
>> I am indeed using an extractor, e.g. here's a line from my code:
>> const Tensor<2, dim> gradv = fe_values[velocity].gradient(j, quad);
>>
>
> Ok, so this demonstrates something that I came to my mind only after I'd 
> posted my reply.  What you're asking for on this line is the gradient of 
> the j'th shape function at the quad'th quadrature point. So not the 
> gradient of the velocity (solution) as I'd originally thought. So you'll 
> have to scrap most of what I'd said.
>
> I'm not too familiar with FEM implementations of fluids problems, so I'm 
> going to have to defer to other people to help you with the specifics. I 
> wouldn't want to lead you astray... But have you seen the tutorials that 
> deal with Stokes / Navier-Stokes problems, such as step-22 
> 
>  and 
> 35 
> ?
>  
> I know that they don't use this component syntax, but they might give you a 
> better idea as to how to implement your problem in general. You might also 
> find the module on handling vector valued problems 
>  useful 
> in terms of seeing how the structure of a fluids problem might look like 
> when using / not using extractors in its implementation.
>  
>
>>  It seems they have to do some work to map to the correct indices, i.e. 
>> with
>> const unsigned int component_i = fe.system_to_component_index 
>> 
>> (i).first;
>>
>
> This is the vector component associated with the i'th shape function. I'm 
> not sure that this is helpful for what you're wanting to implement. This 
> function and its friends are discussed in step-8 and the module on handling 
> vector valued problems 
>  but, 
> as I said, I don't think it applies here.
>  
>
>> When I implement this with higher level library, FEniCS, I don't have to 
>> write the summation; but I think I have to write the summation in deal.II; 
>> hence I need to access $\partial_j z_i$, which I'm doing with the S[i][j] 
>> syntax that we discussed. I actually implement something similar to the 
>> integrand of this operator, for a given quadrature point and degree of 
>> freedom, with the lambda function:
>>
> auto c = [](
>> const Tensor<1, dim> _w,
>> const Tensor<2, dim> _gradz,
>> const Tensor<1, dim> _v)
>> {
>> double sum = 0.;
>> 
>> for (unsigned int i = 0; i < dim ; ++i)
>> {
>> for (unsigned int j = 0; j < dim; ++j)
>> {
>>
>>
>> sum += _w[j]*_gradz[i][j]*_v[i];
>> 
>> }
>> }
>> 
>> return sum;
>> };
>>
>  
> No, you shouldn't

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

2017-04-06 Thread Alex Zimmerman



For the record, this makes much more sense written as a tensor contraction, 
rather than grouping $(w \cdot \nabla)$. The paper I'm referencing just 
writes that grouping and the equivalent summation, but skipped over writing 
it as a tensor contraction, which would have helped me a lot. I wrote down 
the equivalence here:

<https://lh3.googleusercontent.com/-BfOP_i7Vx_s/WOYKfP1BodI/UE0/0_3yExW3mGAvbRKhOElaF5rTccfwkHcwgCLcB/s1600/NonlinearNS_TensorContraction.PNG>

On Thursday, April 6, 2017 at 10:41:07 AM UTC+2, Alex Zimmerman wrote:
>
> Correction! When I tested your idea in my code, I didn't swap the 
> positions of v and w, so I had w on the left and v on the right :) Now I 
> see that you're correct, and I'm sure that writing down the contraction by 
> hand would confirm it.
>
> So my question about the indexing of gradv is still open, but you saved me 
> from using that ugly loop. Thanks!
>
> On Thursday, April 6, 2017 at 10:33:46 AM UTC+2, Alex Zimmerman wrote:
>>
>> Thanks for following up.
>>
>> I don't think that 
>> double sum = v*gradz*w 
>>
>> is equivalent to 
>> double sum = 0.; 
>> for (unsigned int i = 0; i < dim ; ++i)
>> {
>> for (unsigned int j = 0; j < dim; ++j)
>> {
>> sum += _w[j]*_gradz[i][j]*_v[i];
>> }
>> }
>>
>> Most importantly, making the change definitely changes the behavior of my 
>> code; but I think this is explained by the term I wrote before which 
>> convects the velocity field, i.e. $[(\mathbf{w} \cdot \nabla) \mathbf{z}] 
>> \cdot \mathbf{v}$. The problem is how the $\nabla$ operator is grouped with 
>> $w$ on the left. The notation might be specific to the continuum mechanics 
>> community. First the dot product must be taken between the vector w and the 
>> gradient operator (which requires viewing the gradient operator as a 
>> vector), and then this result is multiplied by z, and then the dot product 
>> is taken between that result and v. Of course I'm doing this for the first 
>> time, so I could be misunderstanding something.
>>
>> Later on I might want to implement this differently, maybe more like some 
>> of the tutorials you mentioned; but I'm trying to reproduce a result from a 
>> paper which uses this form. It's somewhat unique because it uses Newton's 
>> method to linearize the nonlinear variational form.
>>
>> Now that I write this, I recall that the deal.II homepage News feed links 
>> to someone solving the stationary problem with Newton's method, step-57 
>> <http://www.dealii.org/developer/doxygen/deal.II/step_57.html>. This 
>> didn't show up when I was glancing through the tutorials recently. I'm 
>> going to see if that tutorial helps :)
>>
>> On Wednesday, April 5, 2017 at 8:14:36 PM UTC+2, Jean-Paul Pelteret wrote:
>>>
>>> Hi Alex,
>>>>>
>>>>  
>>>
>>>> Thanks for the clarification, Jean-Paul. 
>>>>
>>>
>>> I'm sorry to say that you shouldn't be too quick in this instance to 
>>> thank me...
>>>  
>>>
>>>> I'm glad to hear that my syntax is correct.
>>>>
>>>
>>>> I am indeed using an extractor, e.g. here's a line from my code:
>>>> const Tensor<2, dim> gradv = fe_values[velocity].gradient(j, quad);
>>>>
>>>
>>> Ok, so this demonstrates something that I came to my mind only after I'd 
>>> posted my reply.  What you're asking for on this line is the gradient of 
>>> the j'th shape function at the quad'th quadrature point. So not the 
>>> gradient of the velocity (solution) as I'd originally thought. So you'll 
>>> have to scrap most of what I'd said.
>>>
>>> I'm not too familiar with FEM implementations of fluids problems, so I'm 
>>> going to have to defer to other people to help you with the specifics. I 
>>> wouldn't want to lead you astray... But have you seen the tutorials that 
>>> deal with Stokes / Navier-Stokes problems, such as step-22 
>>> <https://dealii.org/8.4.1/doxygen/deal.II/step_22.html#StokesProblemassemble_system>
>>>  and 
>>> 35 
>>> <https://dealii.org/8.4.1/doxygen/deal.II/step_35.html#ThecodeNavierStokesProjectionassemble_advection_termcodemethodandrelated>?
>>>  
>>> I know that they don't use this component syntax, but they might give you a 
>>> better idea as to how to implement your problem in general. You might also 
>>> find the module on handling vector valued problems 
>>> <https://dealii.org/8.4.1/doxygen/deal.II/gr

[deal.II] Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

2017-04-05 Thread Alex Zimmerman

I am debugging a code where part of my weak form requires indexing into the 
Tensor<2,dim> that results from getting the gradient of a Tensor<1,dim> (in 
this case, a velocity vector).

I found the convention for the index notation 
here: http://dealii.org/8.4.1/doxygen/deal.II/classFEValuesViews_1_1Vector.html

The important part of that documentation for me is that "The gradient of a 
vector $d_k, 0 <= k < dim$ is defined as $S_{ij} = \frac{\partial 
d_i}{\partial x_j}, 0 <= i,j < dim$.

What is the exact syntax for getting component $S_{ij}$ in my code? For a 
Tensor<2,dim> S

I am currently assuming that I want 
S[i][j]

But I am not 100% sure that don't have this backwards. I have reviewed the 
documentation about how these tensors are rolled/unrolled; but I'm having 
trouble devising a test to ensure that I am understanding this correctly, 
and I'm guessing that this is something quite obvious to most users.

Also it would help if someone could point me toward an existing 
tutorial/example that accesses components of the gradient of a physical 
vector. I had no luck finding one.

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.

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

2017-04-06 Thread Alex Zimmerman

Correction! When I tested your idea in my code, I didn't swap the positions 
of v and w, so I had w on the left and v on the right :) Now I see that 
you're correct, and I'm sure that writing down the contraction by hand 
would confirm it.

So my question about the indexing of gradv is still open, but you saved me 
from using that ugly loop. Thanks!

On Thursday, April 6, 2017 at 10:33:46 AM UTC+2, Alex Zimmerman wrote:
>
> Thanks for following up.
>
> I don't think that 
> double sum = v*gradz*w 
>
> is equivalent to 
> double sum = 0.; 
> for (unsigned int i = 0; i < dim ; ++i)
> {
> for (unsigned int j = 0; j < dim; ++j)
> {
> sum += _w[j]*_gradz[i][j]*_v[i];
> }
> }
>
> Most importantly, making the change definitely changes the behavior of my 
> code; but I think this is explained by the term I wrote before which 
> convects the velocity field, i.e. $[(\mathbf{w} \cdot \nabla) \mathbf{z}] 
> \cdot \mathbf{v}$. The problem is how the $\nabla$ operator is grouped with 
> $w$ on the left. The notation might be specific to the continuum mechanics 
> community. First the dot product must be taken between the vector w and the 
> gradient operator (which requires viewing the gradient operator as a 
> vector), and then this result is multiplied by z, and then the dot product 
> is taken between that result and v. Of course I'm doing this for the first 
> time, so I could be misunderstanding something.
>
> Later on I might want to implement this differently, maybe more like some 
> of the tutorials you mentioned; but I'm trying to reproduce a result from a 
> paper which uses this form. It's somewhat unique because it uses Newton's 
> method to linearize the nonlinear variational form.
>
> Now that I write this, I recall that the deal.II homepage News feed links 
> to someone solving the stationary problem with Newton's method, step-57 
> <http://www.dealii.org/developer/doxygen/deal.II/step_57.html>. This 
> didn't show up when I was glancing through the tutorials recently. I'm 
> going to see if that tutorial helps :)
>
> On Wednesday, April 5, 2017 at 8:14:36 PM UTC+2, Jean-Paul Pelteret wrote:
>>
>> Hi Alex,
>>>>
>>>  
>>
>>> Thanks for the clarification, Jean-Paul. 
>>>
>>
>> I'm sorry to say that you shouldn't be too quick in this instance to 
>> thank me...
>>  
>>
>>> I'm glad to hear that my syntax is correct.
>>>
>>
>>> I am indeed using an extractor, e.g. here's a line from my code:
>>> const Tensor<2, dim> gradv = fe_values[velocity].gradient(j, quad);
>>>
>>
>> Ok, so this demonstrates something that I came to my mind only after I'd 
>> posted my reply.  What you're asking for on this line is the gradient of 
>> the j'th shape function at the quad'th quadrature point. So not the 
>> gradient of the velocity (solution) as I'd originally thought. So you'll 
>> have to scrap most of what I'd said.
>>
>> I'm not too familiar with FEM implementations of fluids problems, so I'm 
>> going to have to defer to other people to help you with the specifics. I 
>> wouldn't want to lead you astray... But have you seen the tutorials that 
>> deal with Stokes / Navier-Stokes problems, such as step-22 
>> <https://dealii.org/8.4.1/doxygen/deal.II/step_22.html#StokesProblemassemble_system>
>>  and 
>> 35 
>> <https://dealii.org/8.4.1/doxygen/deal.II/step_35.html#ThecodeNavierStokesProjectionassemble_advection_termcodemethodandrelated>?
>>  
>> I know that they don't use this component syntax, but they might give you a 
>> better idea as to how to implement your problem in general. You might also 
>> find the module on handling vector valued problems 
>> <https://dealii.org/8.4.1/doxygen/deal.II/group__vector__valued.html> useful 
>> in terms of seeing how the structure of a fluids problem might look like 
>> when using / not using extractors in its implementation.
>>  
>>
>>>  It seems they have to do some work to map to the correct indices, i.e. 
>>> with
>>> const unsigned int component_i = fe.system_to_component_index 
>>> <https://www.google.com/url?q=https%3A%2F%2Fdealii.org%2Fdeveloper%2Fdoxygen%2Fdeal.II%2FclassFiniteElement.html%23a27220a135402b96c7e6eecbb04acda56=D=1=AFQjCNH9FPtvXF6muGtnl4nIgc1tGhyt0w>
>>> (i).first;
>>>
>>
>> This is the vector component associated with the i'th shape function. I'm 
>> not sure that this is helpful for what you're wanting to implement. This 
>> function and its friends are discussed in step-8 and the module on handling 
>> vecto

Re: [deal.II] Catching exception for find_active_cell_around_point?

Re: [deal.II] Catching exception for find_active_cell_around_point?

[deal.II] Re: Failing to set up simple test configuration

[deal.II] Re: Failing to set up simple test configuration

[deal.II] Re: Failing to set up simple test configuration

[deal.II] Re: Failing to set up simple test configuration

Re: [deal.II] Why is this asserted to be impossible?

[deal.II] Re: Untraceable "not implemented" error in GDB

[deal.II] Why is this asserted to be impossible?

Re: [deal.II] Re: Failing to set up simple test configuration

Re: [deal.II] Re: Failing to set up simple test configuration

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

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

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

[deal.II] Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

[deal.II] Re: Indexing a Tensor<2,dim> representing the gradient of a Tensor<1,dim>

18 matches

Site Navigation

Mail list logo

Footer information