Re: [deal.II] constraint around hole / equivalent node

[Wolfgang Bangerth]

On 08/17/2017 10:05 AM, Tuanny Cajuhi wrote:


Currently I am just using set_all_boundary_ids and set_manifold_id to identify 
the nodes around the hole. Is there a way to specify the equivalent node (the 
node in the middle related to the constrained nodes) in each hole and apply 
the boundary conditions directly in this node?


That's the wrong way to see it. Mathematically, you're applying loads to 
faces, not individual nodes. You should set the boundary_id of the faces on 
which you're trying to apply a load to a different value than the other faces. 
You can then use VectorTools::interpolate_boundary_value with that particular 
boundary_id to evaluate the load you want to apply.




Is it also possible to read the equivalent node from the *inp file?


I think I don't quite know what you mean by the "equivalent node". Do you mean 
the center point of the hole? That's not a part of the mesh, so it's not 
usually mentioned in the .inp file.


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] Combining Taylor-Hood and Raviart Thomas spaces with hp::FECollection

[Wolfgang Bangerth]

But this results in the error message:
|

An error occurred in line <936> of file  
in function
 dealii::FiniteElementDomination::Domination 
dealii::FiniteElement<,  
 >::compare_for_face_domination(const dealii::FiniteElement<, 
 >&) const [with int dim = 2; int spacedim = 2]

The violated condition was:
 false


The fact that you end up in the function of the FiniteElement base class means 
that one of the finite element classes on which you are calling this function 
does not implement this virtual function itself.


From your backtrace, I do see that you're ending up in 
FESystem::compare_for_face_domination(), but I can't see where it is trying to 
go from there. If you're in a debugger, can you see which element it's 
currently trying to compare?


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: Reading Abaqus boundary conditions

[Wolfgang Bangerth]

On 08/17/2017 07:35 PM, Jie Cheng wrote:


Thanks for your answer. Now I understand that the problem was deal.II is 
expecting an integer as the surface name so that it can be converted to 
boundary id. So I changed my surface name from "top" to "1" (without quotes). 
But all the faces that are at the boundary still have the boundary id = 0. The 
method that I used to check the boundary id is cell->face(face)->boundary_id().


That should be the way to do it. I don't know whether our Abaqus reader 
actually reads boundary values, though. You may have to take a look at the 
source code.



I expected some boundary ids to be 1. But deal.II was able to figure out how 
many faces are at the boundary. What did I miss?  Do you have a sample Abaqus 
file that deal.II can process (read mesh and boundary IDs)?


Take a look at the ones here:
  https://github.com/dealii/dealii/tree/master/tests/grid/grids/abaqus

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] Re: Reading Abaqus boundary conditions

[Jie Cheng]

Hi Jean-Paul

Thanks for your answer. Now I understand that the problem was deal.II is 
expecting an integer as the surface name so that it can be converted to 
boundary id. So I changed my surface name from "top" to "1" (without 
quotes). But all the faces that are at the boundary still have the boundary 
id = 0. The method that I used to check the boundary id is 
cell->face(face)->boundary_id(). 

I expected some boundary ids to be 1. But deal.II was able to figure out 
how many faces are at the boundary. What did I miss?  Do you have a sample 
Abaqus file that deal.II can process (read mesh and boundary IDs)?

Thanks
Jie
 
 
On Thursday, August 17, 2017 at 7:13:33 PM UTC-4, Jean-Paul Pelteret wrote:
>
> Hi Jie,
>
> Unfortunately this is not possible to do in our current implementation. 
> The format of an Abaqus mesh file is quite general, and suggested by the 
> documentation 
> 
>  our 
> parser has only the capability to read in a file with a very specific 
> format. At this point 
> 
>  
> in the source code you can see what the parser expects for materials and 
> here 
> 
>  
> for surfaces (boundaries). It would be unreasonable to allow any string 
> entries ("names"): since we store our boundary ID's as integers, what would 
> be the correlation between the name you give a surface and the generated 
> boundary id? Furthermore, deal.II doesn't know anything about the physics 
> of your problem, so that your boundary condition represents a constant 
> traction or anything else would, again, be impossible to interpret in 
> general (we would have to generate boundary Functions to match the input 
> data). Abaqus and other FEM packages might be able to read in such a mesh, 
> but in all likelihood they themselves would also have some limitations in 
> terms of the input file format. 
>
> its quite possible that with a mesh of this structure we would simply 
> ignore all of these sections; however, it may also trigger an assertion. 
> What you could do is split/parse the mesh into two parts, with the first 
> being read by read_abaqus() to generate the grid without boundary ID's and 
> the second being something that you parse yourself in order to interpret 
> your specific boundary conditions. I don't think that this would 
> necessarily be trivial to do, because you would have to work out (or 
> duplicate from our source code) the element rotations on each face, etc. 
>  Alternatively, you could just recreate your mesh files with surface ID's 
> (or sidesets, as Cubit calls them) that are compatible with this function. 
> You'd then have to interpret the meaning of each boundary on a case-by-case 
> basis for each mesh.
>
> I hope that this explains in sufficient detail why our mesh reader is as 
> limited as it is.
>
> Regards,
> Jean-Paul
>
> On Thursday, August 17, 2017 at 8:31:07 PM UTC+2, Jie Cheng wrote:
>>
>> Hi all
>>
>> Recently I started to reconstruct my old hand-written finite element code 
>> with deal.II. Although deal.ii offers a lot of useful functionalities that 
>> make my life much easier, there is one thing I find inconvenient and not 
>> sure what to do.
>>
>> I'd like to read the mesh file from Abaqus, which can be done with 
>> GridIn::read_abaqus. But it seems unable to process the boundary conditions 
>> (Dirichlet bc such as displacement) and loads (Neumann bc such as traction, 
>> pressure). The way abaqus uses to express boundary conditions is as 
>> following:
>>
>> *Nset, nset=fix-xy, generate
>>>1,  133,   33
>>> *Elset, elset=fix-xy, generate
>>>   1,  97,  32
>>> ... ...
>>> ** Name: BC-1 Type: Displacement/Rotation
>>> *Boundary
>>> Part-1-1.fix-xy, 1, 1
>>> Part-1-1.fix-xy, 2, 2
>>>
>>
>> Basically it marks the node and element ids on which the bc is defined.
>>
>> And the way abaqus deals with loads is:
>>
>> *Elset, elset=_top_S3, internal, generate
>>>   97,  128,1
>>> *Surface, type=ELEMENT, name=top
>>> _top_S3, S3
>>> ... ...
>>> ** LOADS
>>> ** 
>>> ** Name: Load-1   Type: Surface traction
>>> *Dsload, constant resultant=YES
>>> Part-1-1.top, TRVEC, 10., 0., -1., 0.
>>> ** 
>>>
>>
>> It writes down the element ids and face ids of the faces that we are 
>> interested in.
>>
>> As you can see, both are dependent on the mesh, rather than the geometry. 
>> Is there a way to import this information to deal.II? More specifically, I 
>> want to generate a map of global_dof_index to boundary values for the 
>> boundary conditions, and a non-zero boundary id for the element faces 
>> subjected to load.
>>
>> Thank you
>> Jie
>>
>>
>>
>>

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

Re: [deal.II] Re: about deal.II with CUDA C programming acceleration

[Chih-Che Chueh]

Bruno,



> Let me know once your merger is done so that I can start to install the
> > deal.II with CUDA in the server I use now.
> The merge was done but in the mean time we broke three tests for CUDA
> :-(. I think that it is still worth to try to install deal with CUDA
> and just update later.
>


I can wait for the tests that are done. No worry.




> > The CUDA compiler I use now in the server is shown in the following:
> > [chueh@icycn06 cuda]$ nvcc --version
> > nvcc: NVIDIA (R) Cuda compiler driver
> > Copyright (c) 2005-2015 NVIDIA Corporation
> > Built on Tue_Aug_11_14:27:32_CDT_2015
> > Cuda compilation tools, release 7.5, V7.5.17
> I don't know if that will work. I think we require CUDA 8.0. Because
> the feature is brand new and we are all using CUDA 8.0, I am not sure
> that it will work with CUDA 7.5 (nobody has ever tried).
>


OK! I am going to ask our system administration to have CUDA 8 compiler
version installed in the GPU before I try to install the deal.II with CUDA.




> > Also, I would appreciate to see the detailed instruction on how to
> install
> > deal.II together with CUDA, because I don't know how to do that.
> Yes, I still need to write the documentation. However it should be
> pretty simple. You need CMake 3.9 and then just use
> -DDEAL_II_WITH_CUDA=ON and it should work. Let me know if you have any
> problem.



OK! I see.

Sincerely,

Chih-Che

-- 
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: about deal.II with CUDA C programming acceleration

[Bruno Turcksin]

Chih-che

2017-08-17 3:27 GMT-04:00 Chih-Che Chueh :
> Let me know once your merger is done so that I can start to install the
> deal.II with CUDA in the server I use now.
The merge was done but in the mean time we broke three tests for CUDA
:-(. I think that it is still worth to try to install deal with CUDA
and just update later.

> The CUDA compiler I use now in the server is shown in the following:
> [chueh@icycn06 cuda]$ nvcc --version
> nvcc: NVIDIA (R) Cuda compiler driver
> Copyright (c) 2005-2015 NVIDIA Corporation
> Built on Tue_Aug_11_14:27:32_CDT_2015
> Cuda compilation tools, release 7.5, V7.5.17
I don't know if that will work. I think we require CUDA 8.0. Because
the feature is brand new and we are all using CUDA 8.0, I am not sure
that it will work with CUDA 7.5 (nobody has ever tried).

> Also, I would appreciate to see the detailed instruction on how to install
> deal.II together with CUDA, because I don't know how to do that.
Yes, I still need to write the documentation. However it should be
pretty simple. You need CMake 3.9 and then just use
-DDEAL_II_WITH_CUDA=ON and it should work. Let me know if you have any
problem.

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.

[deal.II] Re: Reading Abaqus boundary conditions

[Jean-Paul Pelteret]

Hi Jie,

Unfortunately this is not possible to do in our current implementation. The 
format of an Abaqus mesh file is quite general, and suggested by the 
documentation 

 our 
parser has only the capability to read in a file with a very specific 
format. At this point 

 
in the source code you can see what the parser expects for materials and 
here 

 
for surfaces (boundaries). It would be unreasonable to allow any string 
entries ("names"): since we store our boundary ID's as integers, what would 
be the correlation between the name you give a surface and the generated 
boundary id? Furthermore, deal.II doesn't know anything about the physics 
of your problem, so that your boundary condition represents a constant 
traction or anything else would, again, be impossible to interpret in 
general (we would have to generate boundary Functions to match the input 
data). Abaqus and other FEM packages might be able to read in such a mesh, 
but in all likelihood they themselves would also have some limitations in 
terms of the input file format. 

its quite possible that with a mesh of this structure we would simply 
ignore all of these sections; however, it may also trigger an assertion. 
What you could do is split/parse the mesh into two parts, with the first 
being read by read_abaqus() to generate the grid without boundary ID's and 
the second being something that you parse yourself in order to interpret 
your specific boundary conditions. I don't think that this would 
necessarily be trivial to do, because you would have to work out (or 
duplicate from our source code) the element rotations on each face, etc. 
 Alternatively, you could just recreate your mesh files with surface ID's 
(or sidesets, as Cubit calls them) that are compatible with this function. 
You'd then have to interpret the meaning of each boundary on a case-by-case 
basis for each mesh.

I hope that this explains in sufficient detail why our mesh reader is as 
limited as it is.

Regards,
Jean-Paul

On Thursday, August 17, 2017 at 8:31:07 PM UTC+2, Jie Cheng wrote:
>
> Hi all
>
> Recently I started to reconstruct my old hand-written finite element code 
> with deal.II. Although deal.ii offers a lot of useful functionalities that 
> make my life much easier, there is one thing I find inconvenient and not 
> sure what to do.
>
> I'd like to read the mesh file from Abaqus, which can be done with 
> GridIn::read_abaqus. But it seems unable to process the boundary conditions 
> (Dirichlet bc such as displacement) and loads (Neumann bc such as traction, 
> pressure). The way abaqus uses to express boundary conditions is as 
> following:
>
> *Nset, nset=fix-xy, generate
>>1,  133,   33
>> *Elset, elset=fix-xy, generate
>>   1,  97,  32
>> ... ...
>> ** Name: BC-1 Type: Displacement/Rotation
>> *Boundary
>> Part-1-1.fix-xy, 1, 1
>> Part-1-1.fix-xy, 2, 2
>>
>
> Basically it marks the node and element ids on which the bc is defined.
>
> And the way abaqus deals with loads is:
>
> *Elset, elset=_top_S3, internal, generate
>>   97,  128,1
>> *Surface, type=ELEMENT, name=top
>> _top_S3, S3
>> ... ...
>> ** LOADS
>> ** 
>> ** Name: Load-1   Type: Surface traction
>> *Dsload, constant resultant=YES
>> Part-1-1.top, TRVEC, 10., 0., -1., 0.
>> ** 
>>
>
> It writes down the element ids and face ids of the faces that we are 
> interested in.
>
> As you can see, both are dependent on the mesh, rather than the geometry. 
> Is there a way to import this information to deal.II? More specifically, I 
> want to generate a map of global_dof_index to boundary values for the 
> boundary conditions, and a non-zero boundary id for the element faces 
> subjected to load.
>
> Thank you
> Jie
>
>
>
>

-- 
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] Reading Abaqus boundary conditions

[Jie Cheng]

Hi all

Recently I started to reconstruct my old hand-written finite element code 
with deal.II. Although deal.ii offers a lot of useful functionalities that 
make my life much easier, there is one thing I find inconvenient and not 
sure what to do.

I'd like to read the mesh file from Abaqus, which can be done with 
GridIn::read_abaqus. But it seems unable to process the boundary conditions 
(Dirichlet bc such as displacement) and loads (Neumann bc such as traction, 
pressure). The way abaqus uses to express boundary conditions is as 
following:

*Nset, nset=fix-xy, generate
>1,  133,   33
> *Elset, elset=fix-xy, generate
>   1,  97,  32
> ... ...
> ** Name: BC-1 Type: Displacement/Rotation
> *Boundary
> Part-1-1.fix-xy, 1, 1
> Part-1-1.fix-xy, 2, 2
>

Basically it marks the node and element ids on which the bc is defined.

And the way abaqus deals with loads is:

*Elset, elset=_top_S3, internal, generate
>   97,  128,1
> *Surface, type=ELEMENT, name=top
> _top_S3, S3
> ... ...
> ** LOADS
> ** 
> ** Name: Load-1   Type: Surface traction
> *Dsload, constant resultant=YES
> Part-1-1.top, TRVEC, 10., 0., -1., 0.
> ** 
>

It writes down the element ids and face ids of the faces that we are 
interested in.

As you can see, both are dependent on the mesh, rather than the geometry. 
Is there a way to import this information to deal.II? More specifically, I 
want to generate a map of global_dof_index to boundary values for the 
boundary conditions, and a non-zero boundary id for the element faces 
subjected to load.

Thank you
Jie



-- 
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] Combining Taylor-Hood and Raviart Thomas spaces with hp::FECollection

[Eldar Khattatov]

Hi,

I am trying to implement a coupled Stokes-Darcy problem using Step-46 
tutorial as an example. So, essentially I would want to use something like 
the following

FESystem fe_stokes(FE_Q(2), dim,   // Stokes pair
FE_Q(1), 1,
FE_Nothing(dim), 1, // Darcy pair
FE_Nothing(), 1,
FE_Nothing(), 1);   // Lagrange multiplier

FESystem fe_darcy(FE_Nothing(), dim, 
   FE_Nothing(), 1,
   FE_RaviartThomas(0), 1,
   FE_DGQ(0), 1,
   FE_DGQ(0), 1);

hp::FECollection fe;
fe.push_back(fe_stokes);
fe.push_back(fe_darcy);

//...

dof_handler.distribute_dofs (fe);


But this results in the error message:

An error occurred in line <936> of file 
 in function
dealii::FiniteElementDomination::Domination 
dealii::FiniteElement<,  
>::compare_for_face_domination(const dealii::FiniteElement<, 
 >&) const [with int dim = 2; int spacedim = 2]
The violated condition was: 
false
Additional information: 
You are trying to use functionality in deal.II that is currently not 
implemented. In many cases, this indicates that there simply didn't appear 
much of a need for it, or that the author of the original code did not have 
the time to implement a particular case. If you hit this exception, it is 
therefore worth the time to look into the code to find out whether you may 
be able to implement the missing functionality. If you do, please consider 
providing a patch to the deal.II development sources (see the deal.II 
website on how to contribute).

Stacktrace:
---
#0  /home/eldar/Libs/DealII_8.5.1/lib/libdeal_II.g.so.9.0.0-pre: 
dealii::FiniteElement<2, 
2>::compare_for_face_domination(dealii::FiniteElement<2, 2> const&) const
#1  /home/eldar/Libs/DealII_8.5.1/lib/libdeal_II.g.so.9.0.0-pre: 
dealii::FESystem<2, 
2>::compare_for_face_domination(dealii::FiniteElement<2, 2> const&) const


>From what I could see the implementation of dealii::FiniteElement<2, 
2>::compare_for_face_domination(dealii::FiniteElement<2, 2> const&) const  
consists of Assert(false, ...) so for some reason what I am trying to do 
was not meant to be done this way. 

Could you please suggest what else could be done, or, maybe, there is just 
another way of approaching coupled problems like this one using Deal.II?

Thank you!

-- 
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] 2D waveguide using Nedelec elements

[Wolfgang Bangerth]

On 08/17/2017 08:59 AM, Rolf Wester wrote:


I would like to compute eigen-solutions of optical waveguides with 
z-dependence ~ exp(-i k_z z) using the deal.ii Nedelec elements. I found 
some resources on this topic but no one that worked for me. I would be 
very appreciative for a link to a deal.ii example that solves the 
optical waveguide eigen-problem or any other help.


Rolf -- I don't know whether anyone has solved this problem already (I 
suspect that there are people), but in any case, there is at least no 
code that's available to me. Absent such a code, you'll have to write 
one yourself. There are of course example programs that solve 
eigenproblems that you can use as a basis, and you only have to change 
the underlying equation you want to solve. Have you tried? What concrete 
problems did you find?


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] constraint around hole / equivalent node

[Tuanny Cajuhi]

Dear all, 

I would like to simulate a compact tension test similar to the one shown 
here [1]. 

Currently I am just using set_all_boundary_ids and set_manifold_id to 
identify the nodes around the hole. Is there a way to specify the 
equivalent node (the node in the middle related to the constrained nodes) 
in each hole and apply the boundary conditions directly in this node?

Is it also possible to read the equivalent node from the *inp file?


Thank you in advance for your help!


[1] 
https://www.researchgate.net/profile/Chi_Seung_Lee2/publication/276171238/figure/fig9/AS:294640864514064@1447259264850/Figure-10-Finite-element-FE-model-of-compact-tension-CT-specimen-for-ABAQUS.png

-- 
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] 2D waveguide using Nedelec elements

[Rolf Wester]

Hi,

I would like to compute eigen-solutions of optical waveguides with 
z-dependence ~ exp(-i k_z z) using the deal.ii Nedelec elements. I found 
some resources on this topic but no one that worked for me. I would be very 
appreciative for a link to a deal.ii example that solves the optical 
waveguide eigen-problem or any other help.

Thank you in anticipation
Regards
Rolf

-- 
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: errors when installing dealii-8.5.1 after successful cmake configuation

[Bruno Turcksin]

2017-08-17 8:45 GMT-04:00 曾元圆 <2012zg...@gmail.com>:
> I tried to install it in a sub-directory of /home and it really worked!
> Thank you so much, but I'm still confused why I can't install it in the
> shared directory. Probably there are some conflicts between Windows
> environment and Linux?
Great! I don't know why you can't install deal in the shared
directory. It has probably something to do with the fact that cmake
generate a Makefile for Linux but Windows is the real "owner" of the
directory.

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] Re: errors when installing dealii-8.5.1 after successful cmake configuation

[曾元圆]

I tried to install it in a sub-directory of /home and it really worked! 
Thank you so much, but I'm still confused why I can't install it in the 
shared directory. Probably there are some conflicts between Windows 
environment and Linux?

在 2017年8月17日星期四 UTC+8下午8:23:48，Bruno Turcksin写道：
>
> Do you have the same problem if you try to install deal.II in a 
> directory that is not shared with windows? 
>
> Best, 
>
> Bruno 
>
> 2017-08-17 8:18 GMT-04:00 曾元圆 <2012...@gmail.com >: 
> > Yes, I have deleted the previous dealii and restart from unpack the 
> > compressed package, so I think the name of the parent directory is not 
> the 
> > problem. 
> > 
> > I have googled the reason for "Scanning dependencies of target 
> > expand_instantiations_exe 
> > cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend.make:4: 
> *** 
> > missing separator.  Stop." 
> > and it is probably caused by the default editor on my Linux system(some 
> > error occurs if confuse Tab with space) so I have changed the default 
> editor 
> > to vim but still doesn't work. 
> > 
> > Then I checked the file under the directory of the error message 
> > (build/cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/) 
> > open the file "depend.make", and find the following file content: 
> > 
> > # CMAKE generated file: DO NOT EDIT! 
> > # Generated by "Unix Makefiles" Generator, CMake Version 3.5 
> > 
> > 
> cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/expand_instantiations.cc.o:
>  
>
> > ../cmake/scripts/expand_instantiations.cc 
> > 
> > I'm not sure if this is where the error lies and don't know how to solve 
> > this. Sincerely hope someone can help me with this. 
>

-- 
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: errors when installing dealii-8.5.1 after successful cmake configuation

[Bruno Turcksin]

Do you have the same problem if you try to install deal.II in a
directory that is not shared with windows?

Best,

Bruno

2017-08-17 8:18 GMT-04:00 曾元圆 <2012zg...@gmail.com>:
> Yes, I have deleted the previous dealii and restart from unpack the
> compressed package, so I think the name of the parent directory is not the
> problem.
>
> I have googled the reason for "Scanning dependencies of target
> expand_instantiations_exe
> cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend.make:4: ***
> missing separator.  Stop."
> and it is probably caused by the default editor on my Linux system(some
> error occurs if confuse Tab with space) so I have changed the default editor
> to vim but still doesn't work.
>
> Then I checked the file under the directory of the error message
> (build/cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/)
> open the file "depend.make", and find the following file content:
>
> # CMAKE generated file: DO NOT EDIT!
> # Generated by "Unix Makefiles" Generator, CMake Version 3.5
>
> cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/expand_instantiations.cc.o:
> ../cmake/scripts/expand_instantiations.cc
>
> I'm not sure if this is where the error lies and don't know how to solve
> this. Sincerely hope someone can help me with this.

-- 
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: errors when installing dealii-8.5.1 after successful cmake configuation

[曾元圆]

Yes, I have deleted the previous dealii and restart from unpack the 
compressed package, so I think the name of the parent directory is not the 
problem. 

I have googled the reason for "Scanning dependencies of target 
expand_instantiations_exe
cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend.make:4: *** 
missing separator.  Stop." 
and it is probably caused by the default editor on my Linux system(some 
error occurs if confuse Tab with space) so I have changed the default 
editor to vim but still doesn't work. 

Then I checked the file under the directory of the error message (build
/cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/) 
open the file "depend.make", and find the following file content:

# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.5

cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/expand_instantiations.cc.o:
 
../cmake/scripts/expand_instantiations.cc

I'm not sure if this is where the error lies and don't know how to solve 
this. Sincerely hope someone can help me with this.

在 2017年8月17日星期四 UTC+8下午7:35:59，Jean-Paul Pelteret写道：
>
> Hi,
>
> Did you delete your build directory after renaming the parent directory? 
> If not, then you might want to do so and try to configure and build deal.II 
> again. Sometimes CMake caches some data that remains stale even after a 
> project is reconfigured. 
>
> I hope that this helps,
> Jean-Paul
>  
>
>> -- Build files have been written to: /mnt/hgfs/My_code/dealii/build
>> dyfluid@dyfluid:/mnt/hgfs/My_code/dealii/build$ make
>> Scanning dependencies of target expand_instantiations_exe
>> cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend.make:4: *** 
>> missing separator.  Stop.
>> CMakeFiles/Makefile2:381: recipe for target 
>> 'cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/all' failed
>> make[1]: *** [cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/all] 
>> Error 2
>> Makefile:127: recipe for target 'all' failed
>> make: *** [all] Error 2
>>
>

-- 
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: errors when installing dealii-8.5.1 after successful cmake configuation

[Jean-Paul Pelteret]

Hi,

Did you delete your build directory after renaming the parent directory? If 
not, then you might want to do so and try to configure and build deal.II 
again. Sometimes CMake caches some data that remains stale even after a 
project is reconfigured. 

I hope that this helps,
Jean-Paul
 

> -- Build files have been written to: /mnt/hgfs/My_code/dealii/build
> dyfluid@dyfluid:/mnt/hgfs/My_code/dealii/build$ make
> Scanning dependencies of target expand_instantiations_exe
> cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/depend.make:4: *** 
> missing separator.  Stop.
> CMakeFiles/Makefile2:381: recipe for target 
> 'cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/all' failed
> make[1]: *** [cmake/scripts/CMakeFiles/expand_instantiations_exe.dir/all] 
> Error 2
> Makefile:127: recipe for target 'all' failed
> make: *** [all] Error 2
>

-- 
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: about deal.II with CUDA C programming acceleration

[Chih-Che Chueh]

Bruno,

> Is there any reason why you still used the previous way? Is this because
> > your GPU accelerator was launched some years ago so that you are unable
> to
> > use the new simple way?
> The problem with UVM is that it makes it easy to write bad code. I am
> working on a code where we use UVM and it happens quite often that we
> run some code that was intended for the GPU on the CPU. Because of UVM
> it works but at the cost of performance and so it is harder to detect
> that you made a mistake. Another advantage of copying the data
> manually is that you don't hide the costly copy operation. This is
> also the philosophy used in Kokkos. So yes UVM makes writing the code
> easier but you need to be a lot more careful when you write the code
> if you don't want to perform a bunch of useless copy. Of course, if
> you have NVLink it doesn't matter but that only works for POWER chips
> which most people don't have access to.
>

That is a convincing reason for you to do so. I know it now. Thanks!

Let me know once your merger is done so that I can start to install the
deal.II with CUDA in the server I use now.

The CUDA compiler I use now in the server is shown in the following:
[chueh@icycn06 cuda]$ nvcc --version
nvcc: NVIDIA (R) Cuda compiler driver
Copyright (c) 2005-2015 NVIDIA Corporation
Built on Tue_Aug_11_14:27:32_CDT_2015
Cuda compilation tools, release 7.5, V7.5.17

Also, I would appreciate to see the detailed instruction on how to install
deal.II together with CUDA, because I don't know how to do that.

Thanks!

Sincerely,

Chih-Che

-- 
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: errors when installing dealii-8.5.1 after successful cmake configuation

[曾元圆]

Thank you for your reply, I have changed the folder name but it seems 
doesn't work. I'm trying to install dealii on the virtual machine named 
dyfluid. And  /mnt/hgfs/My_code is the shared directory with my Windows 
system. 



dyfluid@dyfluid:/mnt/hgfs/My_code$ cd dealii
dyfluid@dyfluid:/mnt/hgfs/My_code/dealii$ mkdir build
dyfluid@dyfluid:/mnt/hgfs/My_code/dealii$ cd build/
dyfluid@dyfluid:/mnt/hgfs/My_code/dealii/build$ cmake 
-DCMAKE_INSTALL_PREFIX=/mnt/hgfs/My_code/dealii/lib ..
-- This is CMake 3.5.1
-- 
-- Include /mnt/hgfs/My_code/dealii/cmake/setup_external_macros.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_add_flags.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_check_compiler_setup.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_check_cxx_compiler_bug.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_check_mpi_interface.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_clear_cmake_required.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_configure_feature.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_add_definitions.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_add_library.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_add_test.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_find_file.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_find_library.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_find_path.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_initialize_cached_variables.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_insource_setup_target.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_invoke_autopilot.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_package_handle.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_pickup_tests.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_query_git_information.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_deal_ii_setup_target.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_decorate_with_stars.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_enable_if_links.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_enable_if_supported.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_enable_language_optional.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_evaluate_expression.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_expand_instantiations.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_filter_system_libraries.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_find_package.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_find_system_library.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_item_matches.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_purge_feature.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_push_cmake_required.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_register_feature.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_remove_duplicates.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_replace_flag.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_reset_cmake_required.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_setup_source_list.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_setup_unity_target.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_set_if_empty.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_strip_flag.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_switch_library_preference.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_to_string.cmake
-- Include 
/mnt/hgfs/My_code/dealii/cmake/macros/macro_to_string_and_add_prefix.cmake
-- Include /mnt/hgfs/My_code/dealii/cmake/macros/macro_verbose_include.cmake
-- 
-- Include /mnt/hgfs/My_code/dealii/cmake/setup_cached_variables.cmake
-- The CXX compiler identification is GNU 5.4.0
-- The C compiler identification is GNU 5.4.0
-- 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
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- 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
-- Detecting C compile features
-- Detecting C compile features - done
-- No working Fortran compiler found, disabling Fortran
-- 
-- Include /mnt/hgfs/My_code/dealii/cmake/setup_deal_ii.cmake
-- 
-- Include /mnt/hgfs/My_code/dealii/cmake/setup_compiler_flags.cmake
-- Performing Test