date:20180205

Re: [deal.II] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Weixiong Zheng

A might-be-sloppy resolution I came out is to use boost to transform 
SOURCE_DIR macro to string, which is
#include 
...
void test ()
{
  ...
  std::string string_from_macro = BOOST_PP_STRINGIZE(SOURCE_DIR);
  ...
}

It worked, but as what I said, in a sloppy way. I'd be happy to see what 
you guys have in mind.

在 2018年2月5日星期一 UTC-8下午10:37:38，Weixiong Zheng写道：
>
> Thanks Matthias,
>
> What I've tried is to 
> ADD_DEFINITION(-DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}) in the 
> CMakeLists.txt in the test directory. I tried tesing SOURCE_DIR in *.cc 
> file like: std::cout << SOURCE_DIR << std::endl;
>
> When I did "make", screen printout shows: 
> ":2:20: note: expanded from here
>
> #define SOURCE_DIR /Users/GrillCheese/UCB/Research/xtrans/tests/mesh
>
> Following that it has errors like:
>
> */Users/GrillCheese/UCB/Research/xtrans/tests/mesh/mesh_generator_01.cc:57:17:
>  
> **error: **expected expression*
>
>  std::cout << (SOURCE_DIR) << std::endl;
> and
>
> */Users/GrillCheese/UCB/Research/xtrans/tests/mesh/mesh_generator_01.cc:57:17:
>  
> **error: **use of undeclared identifier 'Users'*
>
> *:2:21: **note: *expanded from here
>
> #define SOURCE_DIR /Users/GrillCheese/UCB/Research/xtrans/tests/mesh
> and other same type of error saying "use of undeclared identifier 'xxx'" 
> where xxx can be GrillCheese, UCB, Research etc.
>
> Anything obviously wrong to you?
>
> Thanks,
> Weixiong
>
>
>
> 在 2018年2月5日星期一 UTC-8下午9:25:22，Matthias Maier写道：
>>
>>
>> On Mon, Feb  5, 2018, at 22:15 CST, Weixiong Zheng  
>> wrote: 
>>
>> > Hello All, 
>> > 
>> > I am trying to get unit test work for my project. It works until 
>> reaching 
>> > the point of reading input data. I tried to specify the directory using 
>> > getcwd() though it didn't work with ctest. I noticed there was another 
>> user 
>> > having the same issue and the resolution was to use SOURCE_DIR directly 
>> in 
>> > *.cc file. It turns out it was not recognized. Any quick idea how to 
>> fix it 
>> > would be appreciated. Thanks! 
>>
>> SOURCE_DIR is defined when compiling the *.cc file of a test [1]. For 
>> example, if you have the test layout 
>>
>>   my_test.cc 
>>   my_test.output 
>>
>> and you call DEAL_II_PICKUP_TESTS() in that subdirectory. In that case 
>> the my_test.cc file will be compiled with a compiler flag similar to 
>>
>>  -DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} 
>>
>> It is not available in any other compilation unit (i.e. *.cc file). Or 
>> for the second class of tests where you specify a *.prm file [2]. 
>>
>> Best, 
>> Matthias 
>>
>> [1] The SOURCE_DIR preprocessor definition is set up in line 266 of the 
>> macro cmake/macros/macro_deal_ii_add_test.cmake. 
>>
>> [2] In this case a test gets the full path to the parameter file as 
>> first argument. So simply stripping of the filename should be enough to 
>> get the source directory of the tests. 
>>
>

-- 
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] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Weixiong Zheng

Thanks Matthias,

What I've tried is to 
ADD_DEFINITION(-DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}) in the 
CMakeLists.txt in the test directory. I tried tesing SOURCE_DIR in *.cc 
file like: std::cout << SOURCE_DIR << std::endl;

When I did "make", screen printout shows: 
":2:20: note: expanded from here

#define SOURCE_DIR /Users/GrillCheese/UCB/Research/xtrans/tests/mesh

Following that it has errors like:

*/Users/GrillCheese/UCB/Research/xtrans/tests/mesh/mesh_generator_01.cc:57:17: 
**error: **expected expression*

 std::cout << (SOURCE_DIR) << std::endl;
and

*/Users/GrillCheese/UCB/Research/xtrans/tests/mesh/mesh_generator_01.cc:57:17: 
**error: **use of undeclared identifier 'Users'*

*:2:21: **note: *expanded from here

#define SOURCE_DIR /Users/GrillCheese/UCB/Research/xtrans/tests/mesh
and other same type of error saying "use of undeclared identifier 'xxx'" 
where xxx can be GrillCheese, UCB, Research etc.

Anything obviously wrong to you?

Thanks,
Weixiong



在 2018年2月5日星期一 UTC-8下午9:25:22，Matthias Maier写道：
>
>
> On Mon, Feb  5, 2018, at 22:15 CST, Weixiong Zheng  > wrote: 
>
> > Hello All, 
> > 
> > I am trying to get unit test work for my project. It works until 
> reaching 
> > the point of reading input data. I tried to specify the directory using 
> > getcwd() though it didn't work with ctest. I noticed there was another 
> user 
> > having the same issue and the resolution was to use SOURCE_DIR directly 
> in 
> > *.cc file. It turns out it was not recognized. Any quick idea how to fix 
> it 
> > would be appreciated. Thanks! 
>
> SOURCE_DIR is defined when compiling the *.cc file of a test [1]. For 
> example, if you have the test layout 
>
>   my_test.cc 
>   my_test.output 
>
> and you call DEAL_II_PICKUP_TESTS() in that subdirectory. In that case 
> the my_test.cc file will be compiled with a compiler flag similar to 
>
>  -DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR} 
>
> It is not available in any other compilation unit (i.e. *.cc file). Or 
> for the second class of tests where you specify a *.prm file [2]. 
>
> Best, 
> Matthias 
>
> [1] The SOURCE_DIR preprocessor definition is set up in line 266 of the 
> macro cmake/macros/macro_deal_ii_add_test.cmake. 
>
> [2] In this case a test gets the full path to the parameter file as 
> first argument. So simply stripping of the filename should be enough to 
> get the source directory of the tests. 
>

-- 
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] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Weixiong Zheng



在 2018年2月5日星期一 UTC-8下午8:55:19，Wolfgang Bangerth写道：
>
> On 02/05/2018 09:15 PM, Weixiong Zheng wrote: 
> > 
> > I am trying to get unit test work for my project. It works until 
> reaching the 
> > point of reading input data. I tried to specify the directory using 
> getcwd() 
> > though it didn't work with ctest. I noticed there was another user 
> having the 
> > same issue and the resolution was to use SOURCE_DIR directly in *.cc 
> file. It 
> > turns out it was not recognized. Any quick idea how to fix it would be 
> > appreciated. Thanks! 
>
> I would say I set it up pretty much like the advanced setting following test 
suites in user projects 
 webpage 
without actively setting up SOURCE_DIR.

> How exactly do you set up your tests? Are you using the deal.II cmake 
> snippets 
> for a testsuite? 
>
> SOURCE_DIR is not something that is supported by default -- it's something 
> you 
> have to actively make sure you set up. 
>
> 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] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Matthias Maier

On Mon, Feb  5, 2018, at 22:15 CST, Weixiong Zheng  wrote:

> Hello All,
>
> I am trying to get unit test work for my project. It works until reaching 
> the point of reading input data. I tried to specify the directory using 
> getcwd() though it didn't work with ctest. I noticed there was another user 
> having the same issue and the resolution was to use SOURCE_DIR directly in 
> *.cc file. It turns out it was not recognized. Any quick idea how to fix it 
> would be appreciated. Thanks!

SOURCE_DIR is defined when compiling the *.cc file of a test [1]. For
example, if you have the test layout

  my_test.cc
  my_test.output

and you call DEAL_II_PICKUP_TESTS() in that subdirectory. In that case
the my_test.cc file will be compiled with a compiler flag similar to

 -DSOURCE_DIR=${CMAKE_CURRENT_SOURCE_DIR}

It is not available in any other compilation unit (i.e. *.cc file). Or
for the second class of tests where you specify a *.prm file [2].

Best,
Matthias

[1] The SOURCE_DIR preprocessor definition is set up in line 266 of the
macro cmake/macros/macro_deal_ii_add_test.cmake.

[2] In this case a test gets the full path to the parameter file as
first argument. So simply stripping of the filename should be enough to
get the source directory of the tests.

-- 
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] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Wolfgang Bangerth


On 02/05/2018 09:15 PM, Weixiong Zheng wrote:


I am trying to get unit test work for my project. It works until reaching the 
point of reading input data. I tried to specify the directory using getcwd() 
though it didn't work with ctest. I noticed there was another user having the 
same issue and the resolution was to use SOURCE_DIR directly in *.cc file. It 
turns out it was not recognized. Any quick idea how to fix it would be 
appreciated. Thanks!


How exactly do you set up your tests? Are you using the deal.II cmake snippets 
for a testsuite?


SOURCE_DIR is not something that is supported by default -- it's something you 
have to actively make sure you set up.


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

[deal.II] SOURCE_DIR for input data reading in user project unit testing

2018-02-05 Thread Weixiong Zheng

Hello All,

I am trying to get unit test work for my project. It works until reaching 
the point of reading input data. I tried to specify the directory using 
getcwd() though it didn't work with ctest. I noticed there was another user 
having the same issue and the resolution was to use SOURCE_DIR directly in 
*.cc file. It turns out it was not recognized. Any quick idea how to fix it 
would be appreciated. Thanks!

Weixiong

-- 
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] Relacement of laplace and Mass matrix usage with cell wise assembly for v-equation in step-23

2018-02-05 Thread Wolfgang Bangerth

On 01/30/2018 07:53 AM, Dulcimer0909 wrote:

     for(unsigned int i = 0; i < dofs_per_cell; i++)
     {
     for (unsigned int j = 0; j < dofs_per_cell; j++)
     {
     matrix_v.add (local_dof_indices[i],
    local_dof_indices[j],
    cell_matrix(i,j));
     }
     system_rhs(local_dof_indices[i]) += cell_rhs(i);

This is the place I pointed out in the other mail: you add to matrix_v 
and system_rhs on each cell, but you never set them to zero.

>  for(unsigned int i = 0; i < dofs_per_cell; ++i)
>  {
>  for(unsigned int j = 0; j < dofs_per_cell; ++j)
>  {
> [...]
>  cell_rhs_1(i) +=
> /*(MV^(n-1) - k(theta*A*U^(n) +
> (1-theta)*A*U^(n-1))*/
>(
> fe_values.shape_value(i, q_index) *
> fe_values.shape_value(j, q_index)
> *
> old_v

This cannot be correct. The assembly of cell_rhs_1(i) cannot include the 
shape function shape_value(j,q_index). Assembly of the rhs must be in a 
loop only over i, not in the loop over j.

As for debugging these problems, you should also try to run these sorts 
of things on only one cell, for example. If you only change the system 
assembly for the second equation, then output the rhs and matrix for the 
v-system just before solving for both of the old code and for your 
modification. They need to be the same. If they're not, you know where 
your problem lies.

Best
 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: Usage of the laplace-matrix in example 23

2018-02-05 Thread Wolfgang Bangerth



Dulcimer,
it is difficult for any of us to just look at a piece of code and tell 
where exactly things are going wrong. You'll have to learn to debug what 
is happening in your case, and for this it is easiest if you make the 
problem as simple as possible -- for example, use zero boundary values, 
zero right hand sides, no hanging nodes, etc. You can then reduce the 
amount of code that deal with each of these cases. This reduces the 
number of possible sources of the problem.


From a cursory look at your code, I see that you are adding 
contributions to the rhs vectors and the system matrix on each cell. But 
I don't see that you set these vectors and the matrix to zero before 
your loop over all cells. I may be missing this, but it seems like a bug.


Best
 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] modifying of only one component of solution

2018-02-05 Thread Marek Čapek

Hi,
I have Cahn-Hilliard system - scalar equation for
phase field and chemical potential. I tried to modify only
the phase field part of solution in distributed code like 
step-40:

template
> void Main::postprocess_solution(){
>
> nsSystem.computing_timer.enter_subsection("Solution postprocessing");
>
>
>
> std::vector 
> selected_dofs(dofHandlerCrate.dof_handler_phase->n_locally_owned_dofs());
>
>
> //here I choose to modify only the phase-field part of solution
> std::vector component_mask_vec = {true,false};
>
> ComponentMask component_mask(component_mask_vec);
>
> //modified_phase_solution is the nonghosted trilinoswrappers mpi vector
> modified_phase_solution.reinit 
> (dofHandlerCrate.dof_handler_phase->locally_owned_dofs(), MPI_COMM_WORLD);
>
> IndexSet locally_owned 
> =dofHandlerCrate.dof_handler_phase->locally_owned_dofs();
> 
> DoFTools::extract_dofs(*dofHandlerCrate.dof_handler_phase,component_mask,selected_dofs);
>
> for (types::global_dof_index i=0; 
> in_locally_owned_dofs(); ++i){
> int global_index=locally_owned.nth_index_in_set(i);
> double value = globalCrateCurrent.solution_phase_n(global_index);
>
> if(selected_dofs[i]==true){
>
//modify if it is phase field part of solution 
>
 modified_phase_solution(global_index)=truncate_conc(value);
>  }
> else
>
   //else let it be
>
  modified_phase_solution(global_index)=value;
>
> }
>
> modified_phase_solution.compress(VectorOperation::insert);
>
> //globalCrateCurrent.solution_phase_n is ghosted vector of solution
> globalCrateCurrent.solution_phase_n=modified_phase_solution;
>
> nsSystem.computing_timer.leave_subsection("Solution postprocessing");
>
> }
>

However the solution does not get modified. It appears to me, that 
selected_dofs vector
is filled with false values.Maybe I use wrongly the function
DoFTools::extract_dofs for the distributed case.
Could You please provide me guidance, how to use it properly?

Thanks

Marek

Dne pondělí 28. srpna 2017 18:55:30 UTC+2 Wolfgang Bangerth napsal(a):
>
> On 08/27/2017 11:53 AM, Marek Čapek wrote: 
> > 
> > 
> > I am getting the solution in 
> > 
> >PetscWrappers::MPI::Vector solution_phase_n; 
> > 
> > I am interested in modifying the vector of the solution - I 
> > want to cut the undershoots and overshoots in phase-field component 
> > of the solution. Namely I have values of phase field like -1.005 or 
> 1.005, 
> > however they should be only in <-1,1>. 
> > Is it possible to modify only the relevant parts of the 
> > PetscWrappers::MPI::Vector ? 
> > 
> > I want to get  afterwards the solution values and gradients using 
> > 
> > fe_v_phase.get_function_values 
> > fe_v_phase.get_function_gradients 
> > 
> > to get the "repaired" values and gradients of phase field. 
> > 
> > Or should I split the system, ie. firstly solve for the phase 
> > field, then modify the phase field solution and afterwards 
> > solve for chemical potential? 
>
> The easiest solution is probably to use a 
> PETScWrappers::MPI::BlockVector with two blocks that corresponds to the 
> two variables. You would then just apply the operation on one of the 
> blocks. This may require you to also substructure your matrix into 
> blocks, but all of your solvers should continue to work. In particular, 
> just because your matrix is substructured does not imply that you have 
> to solve one equation at the time (though you can). 
>
> The alternative is to figure out which elements of your vector 
> correspond to the phase-field. Namespace DoFTools has functions that 
> give you a mask or IndexSet that indicates which variables belong to one 
> particular vector component. You would then just operate on those vector 
> elements that are listed in the mask/IndexSet. 
>
> 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: AW: [deal.II] step-42 clarification

2018-02-05 Thread Timo Heister

> In such a case, one wants to restart the computations

We have support for snapshot&resume in parallel with adaptive meshes
by using the SolutionTransfer class. See "Use for serialization" in
https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dealii.org_developer_doxygen_deal.II_classparallel-5F1-5F1distributed-5F1-5F1SolutionTransfer.html&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=88KR9zh1f_gaVgWHpZwwXXlaOCduKgZ1yzsuERztdmU&s=Q549G3WmW1DtS06Yq9GyH98gIg8Rl44Ezac7I1Fc1Tc&e=
 

You can also check out how we do things in ASPECT:
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_geodynamics_aspect_blob_master_source_simulator_checkpoint-5Frestart.cc&d=DwIBaQ&c=Ngd-ta5yRYsqeUsEDgxhcqsYYY1Xs5ogLxWPA_2Wlc4&r=4k7iKXbjGC8LfYxVJJXiaYVu6FRWmEjX38S7JmlS9Vw&m=88KR9zh1f_gaVgWHpZwwXXlaOCduKgZ1yzsuERztdmU&s=cUF_2LwSAUqoivqPWcoBBBpepBLrCfq8fDSkWlrkBTY&e=
 

-- 
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] SOURCE_DIR for input data reading in user project unit testing

Re: [deal.II] SOURCE_DIR for input data reading in user project unit testing

Re: [deal.II] SOURCE_DIR for input data reading in user project unit testing

Re: [deal.II] SOURCE_DIR for input data reading in user project unit testing

Re: [deal.II] SOURCE_DIR for input data reading in user project unit testing

[deal.II] SOURCE_DIR for input data reading in user project unit testing

Re: [deal.II] Relacement of laplace and Mass matrix usage with cell wise assembly for v-equation in step-23

Re: [deal.II] Re: Usage of the laplace-matrix in example 23

Re: [deal.II] modifying of only one component of solution

Re: AW: [deal.II] step-42 clarification

10 matches

Site Navigation

Mail list logo

Footer information