Re: [deal.II] Applying Multi Point Constraints

[RAJAT ARORA]

Respected Prof. Wolfgang,

I really appreciate your taking the time to reply. Thank you very much.

Yes, by middle element I mean the central layer of the mesh.

Yes you are right. It turns out this is the problem.
I was creating a hyper_rectangle using grid generation class. Then 4 and 5 
corresponded to the -/+ z surface. 
(I used hard coded numbers as it saved time for looping over all the 
elements.)

Now when I am using the same mesh but now reading via read_ucd(), upon 
reading the documentation carefully, I saw that the ordering is changed. So 
4 and 5 now no more correspond to -/+ z surface.

However, If I call cell->face(4)->unit_cell_direction, it still gives 
output as 2, which means that this face is normal to z surface.
This normal direction is for the cell in the natural coordinates, right ? I 
think this is why I am not getting the constraints right.

So, in general, how should I know if the real cell face is normal to -/+ z 
direction ?

Will having a constraint such that both the dofs are locally relevant & not 
locally owned result in anything bad ? I think, it should have no effect 
atleast for that processor on which both these two dofs lie. 
Am I right here ?
- hide quoted text -


On Wednesday, September 7, 2016 at 4:24:52 PM UTC-4, Wolfgang Bangerth 
wrote:
>
>
> > Lets say I have a mesh with 10 X 10 X 3 elements. 
> > 
> > I want to apply constraints such that all the dofs on the +z surface of 
> the 
> > middle element are constrained to be equal to the corresponding dofs on 
> the -z 
> > surface of the middle element. 
>
> What is the "middle" element? The central layer of your mesh? 
>
>
> > std::mapvertex_touched; 
> >  typenameDoFHandler::active_cell_iterator 
> >  cell =dof_handler.begin_active(), 
> >  endc =dof_handler.end(); 
> > 
> > 
> >  for(cell =dof_handler.begin_active();cell !=endc;++cell) 
> >  if(cell->is_ghost()||cell->is_locally_owned()) 
> >  for(unsignedintv =0;v  >  vertex_touched[cell->vertex_index(v)]=false; 
> > 
> > 
> > 
> >  for(cell =dof_handler.begin_active();cell !=endc;++cell) 
> >  if(cell->is_ghost()||cell->is_locally_owned()) 
> >  { 
> >  boolcell_on_pm_z_face =false; 
> > 
> > // donot take into account the cells which are at the top and bottom 
> boundary. 
> > We only need to impose constraints on the middle element. 
> > 
> >  constintface_mz =4;constintface_pz =5; 
> >  if(cell->face(face_mz)->boundary_id()==minus_z_boundary_id || 
> > cell->face(face_pz)->boundary_id()==plus_z_boundary_id) 
> >  { 
> >  cell_on_pm_z_face =true; 
> >  continue; 
> >  } 
>
> Does this ever trigger? You make the assumption that you know that the 
> faces 
> you care about are faces 4 or 5 of a cell. But that may not be the case. 
> In 
> other words, once you pass this block, on how many cells does the rest of 
> the 
> code run? 
>
> The rest of the code does not, at least trigger anything that looks 
> obviously 
> wrong. You need the constraints if at least one of the constraints you 
> want to 
> constrain are locally relevant (i.e., on a locally owned cell or a ghost 
> cell), which is what I think you get. 
>
> But then you also don't say what happens when you run the code. In which 
> way 
> is the result wrong? 
>
> Best 
>   Wolfgang 
>
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
> www: http://www.math.colostate.edu/~bangerth/ 
>

On Wednesday, September 7, 2016 at 4:24:52 PM UTC-4, Wolfgang Bangerth 
wrote:
>
>
> > Lets say I have a mesh with 10 X 10 X 3 elements. 
> > 
> > I want to apply constraints such that all the dofs on the +z surface of 
> the 
> > middle element are constrained to be equal to the corresponding dofs on 
> the -z 
> > surface of the middle element. 
>
> What is the "middle" element? The central layer of your mesh? 
>
>
> > std::mapvertex_touched; 
> >  typenameDoFHandler::active_cell_iterator 
> >  cell =dof_handler.begin_active(), 
> >  endc =dof_handler.end(); 
> > 
> > 
> >  for(cell =dof_handler.begin_active();cell !=endc;++cell) 
> >  if(cell->is_ghost()||cell->is_locally_owned()) 
> >  for(unsignedintv =0;v  >  vertex_touched[cell->vertex_index(v)]=false; 
> > 
> > 
> > 
> >  for(cell =dof_handler.begin_active();cell !=endc;++cell) 
> >  if(cell->is_ghost()||cell->is_locally_owned()) 
> >  { 
> >  boolcell_on_pm_z_face =false; 
> > 
> > // donot take into account the cells which are at the top and bottom 
> boundary. 
> > We only need to impose constraints on the middle element. 
> > 
> >  constintface_mz =4;constintface_pz =5; 
> >  if(cell->face(face_mz)->boundary_id()==minus_z_boundary_id || 
> > cell->face(face_pz)->boundary_id()==plus_z_boundary_id) 
> >  { 
> >  cell_on_pm_z_face =true; 
> >  continue; 
> >  } 
>
> Does this ever trigger? 

Re: [deal.II] Applying Multi Point Constraints

[Wolfgang Bangerth]

Yes you are right. It turns out this is the problem.
I was creating a hyper_rectangle using grid generation class. Then 4 and 5
corresponded to the -/+ z surface.
(I used hard coded numbers as it saved time for looping over all the elements.)

>
> Now when I am using the same mesh but now reading via read_ucd(), upon reading
> the documentation carefully, I saw that the ordering is changed. So 4 and 5
> now no more correspond to -/+ z surface.

It's always a safe bet in debugging other people's codes to challenge their 
underlying assumptions :-)




However, If I call cell->face(4)->unit_cell_direction, it still gives output
as 2, which means that this face is normal to z surface.
This normal direction is for the cell in the natural coordinates, right ?


In the "reference coordinate system" (which we often call the "unit cell 
coordinate system". But that's not the coordinate system you care about.




So, in general, how should I know if the real cell face is normal to -/+ z
direction ?


You could query the z-coordinate of a face's center. Loop over all faces of a 
cell, if you find one whose center's z-coordinate is at the top or bottom of 
the domain, then you have a cell you care about.




Will having a constraint such that both the dofs are locally relevant & not
locally owned result in anything bad ? I think, it should have no effect
atleast for that processor on which both these two dofs lie.
Am I right here ?


Correct.
W.

--

Wolfgang Bangerth  email: bange...@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

[Timo Heister]

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  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
 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.dealii.org_developer_users_testsuite.html=CwIBaQ=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw=WDpmF-SkGP5uKyQ0vKXcggIG-I_RfG1fLlDteZEDQ_s=D427W_TuNHmLUNLsfAJzev5TqwE4D65e65adR2s4VMo=
>  . 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 ..
>

Re: [deal.II] Question concerning BlockSparsityPattern.copy_from() member function

[Bruno Turcksin]

Dustin,

2016-09-07 11:07 GMT-04:00 Dustin Kumor :
> I'm using the function "add_entries" only in combination with the
> DynamicSparsityPattern and not with the SparsityPattern class. Moreover, it
> seems that the DynamicSparsityPattern class doesn't even have a "copy_form"
> function. So I do not really get the point.
Yes, sorry. I didn't realize that you were copying a
DynamicSparsityPattern and not a SparsityPattern.

Best,

Bruno

-- 
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] Question concerning BlockSparsityPattern.copy_from() member function

[Dustin Kumor]

Dear Martin, dear Bruno,

I'm sorry for giving a feedback to your answers that late, but I have been 
really busy with another project and had no time to deal with this problem.

@Martin: After applying the patch I get the same run time results as you 
did. So thank you for figuring out and fixing the problem.

@ Bruno: Of course you are right. The correct name of the functions is 
indeed "make_biorthogonal_sparsity_pattern" and not 
"make_offdiagonal_sparsity_pattern". Sorry for confusing you, but I talked 
to so many people about this problem and it always arised when filling the 
offdiagonal blocks of my block matrix that I just mixed up the terms. 
Concerning your first hint, I'm not quite sure if I understand it 
correctly. I'm using the function "add_entries" only in combination with 
the DynamicSparsityPattern and not with the SparsityPattern class. 
Moreover, it seems that the DynamicSparsityPattern class doesn't even have 
a "copy_form" function. So I do not really get the point.

Best,
Dustin


-- 
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: nearest neighbor

[Daniel Arndt]

Joel,

In GridTools::find_cells_adjacent_to_vertex(dof_handler,center_id) you need 
to give the number of the vertex_number as center_id, not the number of the 
degree of freedom.
Then, you want to use 

Quadrature  
quadrature_formula(dof_handler.get_fe().get_unit_support_points());

to create a Quadrature object that gives you the support points on each 
cell.
Finally, you can output the global dof number and their support point on 
each cell by: 

for (unsigned int j=0; j

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

[Jean-Paul Pelteret]

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://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 
>>  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/dealii-8.4.2/share/deal.II/macros/macro_deal_ii_query_git_information.cmake
> -- Include 

Re: [deal.II] FE_TraceQ using GaussLobatto nodes

[Praveen C]

Hello Martin,

On Wed, Sep 7, 2016 at 11:28 AM, Martin Kronbichler <
kronbichler.mar...@gmail.com> wrote:

> Dear Praveen,
>
>
> > The documentation says that GaussLobatto node-based FE_TraceQ will be
> > implemented in future. Is there any estimate on when this will be
> > available ?
> The documentation is outdated. Indeed, FE_TraceQ is based on the nodes
> of the Gauss-Lobatto quadrature formula. See the code in
> source/fe/fe_trace.cc, constructor call. We somehow forgot to update the
> documentation. I will open a pull request.
>
> This great to know. I will test this in my navier-stokes solver soon.


> > In Interior Embedded DG (IEDG) scheme, you need trace spaces which are
> > continuous on interior faces but discontinuous on boundary faces. Is
> > there a plan to implement such a space in deal.II ?
> Please help me understand your question: You want to have the behavior
> of FE_TraceQ on interior faces and FE_FaceQ at the boundary? Having this
>

Yes. In IEDG, functions are continuous on the union of interior faces and
discontinuous on the union of boundary faces. Here is a reference on IEDG
methods

10.1016/j.jcp.2015.09.024 

kind of distinction is not easily possible because of the way elements
> are organized in deal.II. We logically assign degrees of freedom to the
> vertices, edges, quads and hexes of the elements. In the case of
> FE_TraceQ in 3D, linear functions live on vertices only, whereas for
> quadratics and higher you also put nodes on the midpoints of edges and
> the quads. For FE_FaceQ, we put all degrees of freedom on the quads,
> even though the support points of linears is still at the vertex
> location. This way, we get duplicated degrees of freedom.
>
> If you want to construct such a space, you will need to do some manual
> labor: My suggestion would be that you build FE_FaceQ and then manually
> find constraints that put the vertices (and edges in 3D) that sit on the
> same physical position to the same degree of freedom. It should be
> pretty straight-forward to do so.
>

That is a nice idea and it will achieve what I want. I have to completely
eliminate the constrained dofs so that the global matrix size is reduced,
which is the main reason for using EDG/IEDG instead of HDG.

Thanks
praveen

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

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

[deal.II] Applying Multi Point Constraints

[RAJAT ARORA]

Hello all,

I am trying to apply multi point constraints to a 3D solid mechanics 
problem.
My code used P4est, and PetSc.

Lets say I have a mesh with 10 X 10 X 3 elements.

I want to apply constraints such that all the dofs on the +z surface of the 
middle element are constrained to be equal to the corresponding dofs on the 
-z surface of the middle element.

That is Dof af (X,Y,-z surface) = Dof at (X,Y,+z surface).

Till now I have written this code but this does not seem to be working.
I am not clear with the concept of using Constraint Matrix with parallel 
triangulation.

Can anyone help me to do this and pointout what is the error that I am 
making ?



std::map vertex_touched;
 typename DoFHandler::active_cell_iterator
 cell = dof_handler.begin_active(),
 endc = dof_handler.end();


 for (cell = dof_handler.begin_active(); cell != endc; ++cell)
 if (cell->is_ghost() || cell->is_locally_owned())
 for (unsigned int v = 0; v < GeometryInfo::vertices_per_cell; ++v)
 vertex_touched[cell->vertex_index(v)] = false;
 


 for (cell = dof_handler.begin_active(); cell != endc; ++cell)
 if (cell->is_ghost() || cell->is_locally_owned())
 {
 bool cell_on_pm_z_face = false; 

// donot take into account the cells which are at the top and bottom 
boundary. We only need to impose constraints on the middle element.
 
 const int face_mz = 4; const int face_pz = 5;
 if (cell->face(face_mz)->boundary_id() == minus_z_boundary_id ||
cell->face(face_pz)->boundary_id() == plus_z_boundary_id)
 {
 cell_on_pm_z_face = true;
 continue;
 }


 for (unsigned int v = 0; v < GeometryInfo::vertices_per_face; ++v)
 if(vertex_touched[cell->face(face_mz)->vertex_index(v)] == false)
 {
 vertex_touched[cell->face(face_mz)->vertex_index(v)] = true;
 for (unsigned int d = 0; d < dofs_per_vertex; ++d)
 {
 types::global_dof_index dof1 = cell->face(face_mz)->vertex_dof_index(v, d);
 types::global_dof_index dof2 = cell->face(face_pz)->vertex_dof_index(v, d);
 {
 constraints_mpcs.add_line(dof1);
 constraints_mpcs.add_entry(dof1, dof2, 1.0);
 }
 }
 }
 }



Does constraint matrix need to know include the line when dofs1 and dofs2 
i.e. both of them are not locally owned ?
or constraint matrix need to include the line when atleast of the dofs is 
locally owned ?

 

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

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

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

[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")
>>> -- Configuring done
>>> -- Generating done
>>> -- Build files have been written to: 
>>> /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>>> zimmerman@GRS-LAPTOP:/mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build$
>>>  
>>> make
>>> Scanning dependencies of target step-1
>>> [100%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>>> Linking CXX executable step-1
>>> [100%] Built target step-1
>>
>>  
>>
>> $ ctest
>>
>>  
>>
>> Test project /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>>> Start 1: tests/my_test.debug
>>> 1/1 Test #1: tests/my_test.debug ..***Failed0.59 sec
>>> 0% tests passed, 1 tests failed out of 1
>>> Total Test time (real) =   0.60 sec
>>> The following tests FAILED:
>>>   1 - 

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

[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
>> zimmerman@GRS-LAPTOP:/mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build$
>>  
>> make
>> Scanning dependencies of target step-1
>> [100%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>> Linking CXX executable step-1
>> [100%] Built target step-1
>
>  
>
> $ ctest
>
>  
>
> Test project /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>> Start 1: tests/my_test.debug
>> 1/1 Test #1: tests/my_test.debug ..***Failed0.59 sec
>> 0% tests passed, 1 tests failed out 

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

[Jean-Paul Pelteret]

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")
>> -- Configuring done
>> -- Generating done
>> -- Build files have been written to: 
>> /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>> zimmerman@GRS-LAPTOP:/mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build$
>>  
>> make
>> Scanning dependencies of target step-1
>> [100%] Building CXX object CMakeFiles/step-1.dir/step-1.cc.o
>> Linking CXX executable step-1
>> [100%] Built target step-1
>
>  
>
> $ ctest
>
>  
>
> Test project /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>> Start 1: tests/my_test.debug
>> 1/1 Test #1: tests/my_test.debug ..***Failed0.59 sec
>> 0% tests passed, 1 tests failed out of 1
>> Total Test time (real) =   0.60 sec
>> The following tests FAILED:
>>   1 - tests/my_test.debug (Failed)
>> Errors while running CTest
>> zimmerman@GRS-LAPTOP:/mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build$
>>  
>> ctest
>> Test project /mnt/c/Users/Alexander/UbuntuShared/help/temp/step-1/build
>> Start 1: tests/my_test.debug
>> 1/1 Test #1: tests/my_test.debug ..***Failed0.60 sec
>> 0% tests passed, 1 tests failed