date:20161201

[deal.II] Re: Apply Neumann Boundary condition

2016-12-01 Thread Xin-Bo Qi

You should test your code step by step, figuring out exactly where the 
error occurs. And then propose a technical and accurate question here.
Time is expensive, and the developers offer their kind help to us, then we 
should respect their time and help.

在 2016年12月2日星期五 UTC+8上午7:25:32，benhour@gmail.com写道：
>
> Dear Jean,
> I know that this website is not the code reviewer. I want to apply Neumann 
> boundary condition on the curved side of my domain. It should be note that 
> the domain is symmetry. I have considered half of a circle. It would be 
> very kind of you if you let me know whether it is applied correctly because 
> I think something is wrong when I run my code and my domain completely 
> distorted. I am doubtful about how I applied the boundary condition. For 
> the horizontal axis, I have considered the zero displacement along y-axis 
> because of symmetry. Is it correct? Should I fix the center of the circle 
> as well? How Can I do that? In other words, How can I fix one point 
> (vertex) in 2-D? Looking forward to hearing from you. 
>
> On Thursday, December 1, 2016 at 3:54:44 PM UTC-6, Jean-Paul Pelteret 
> wrote:
>>
>> Dear Benhour,
>>
>> As I explained to someone else 
>> 
>>  
>> the day before yesterday, the point of this forum is not to provide a code 
>> review service without you having done due diligence on your side. Does 
>> this not work as expected? If this is the case, then how is the problem 
>> manifesting itself? Unless you have a specific issue pertaining to the code 
>> that you have posted then I'm afraid that there's no discussion to be had 
>> here.
>>
>> Regards,
>> Jean-Paul
>>
>

-- 
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: Apply Neumann Boundary condition

2016-12-01 Thread benhour . amirian66

Dear Jean,
I know that this website is not the code reviewer. I want to apply Neumann 
boundary condition on the curved side of my domain. It should be note that 
the domain is symmetry. I have considered half of a circle. It would be 
very kind of you if you let me know whether it is applied correctly because 
I think something is wrong when I run my code and my domain completely 
distorted. I am doubtful about how I applied the boundary condition. For 
the horizontal axis, I have considered the zero displacement along y-axis 
because of symmetry. Is it correct? Should I fix the center of the circle 
as well? How Can I do that? In other words, How can I fix one point 
(vertex) in 2-D? Looking forward to hearing from you. 

On Thursday, December 1, 2016 at 3:54:44 PM UTC-6, Jean-Paul Pelteret wrote:
>
> Dear Benhour,
>
> As I explained to someone else 
> 
>  
> the day before yesterday, the point of this forum is not to provide a code 
> review service without you having done due diligence on your side. Does 
> this not work as expected? If this is the case, then how is the problem 
> manifesting itself? Unless you have a specific issue pertaining to the code 
> that you have posted then I'm afraid that there's no discussion to be had 
> here.
>
> Regards,
> Jean-Paul
>

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

[dealii-developers] Promoting developer version documentation in search engines and user forum posts

2016-12-01 Thread Jean-Paul Pelteret

Dear all,

When I answer posts on the forum I try my best to add links to relevant 
portions of the documentation.
I tend to choose (when I remember to do so) those from the developer page 
because I anticipate that these links would exist in perpetuity as we move 
to version 9 and beyond.
As sometimes its easier to search for a key phrase than a specific 
namespace/class/function, I preferentially use Google as opposed to the 
search bar in the Doxygen docs.

These searches typically bring up a mish-mash of older documentation and 
that from the developer version.
For example, searching for the GridTools::find_active_cell_around_point 
 
function (not the most robust construction of a query, but probably a 
typical one) returns links to v8.4.1 and older, and there's not even a link 
on the front page to the latest docs!
This leads me to wonder whether would it be useful (or even possible) to 
promote the developer version of the documentation in search engine results 
in preference to the older versions?
I think that this might be rewarding to the average user because then 
they'd get more exposure to the latest documentation (with all its 
enhancements) and to the newest functionality in deal.II.

Best regards,
J-P

Addendum:
In writing this post, I have just realised that some of the 
classes/functions that I link to may be deprecated and removed in time.
So perhaps I should be linking to the most recent stable version's 
documentation and (if possible) it's results should be returned 
preferentially by search engines.
Does anyone else have any thoughts on what the best practise for this is?

-- 
You received this message because you are subscribed to the Google Groups 
"deal.II developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: mesh quality during deformations using MappingQEulerian

2016-12-01 Thread Jean-Paul Pelteret

Hi Tom,
 

> J-P, you (and the entire dealii community) are a paragon of encouragement, 
>> and I appreciate that very much.  
>>
>
Thank you, your kind words do mean a lot!
 

> here's what I came up with yesterday
>

That's a handy piece of code to keep around. Thanks for sharing it!

This works on a small geometry, thankfully.  Even after mesh modifications 
> from within cubit.  This would not work for remeshing from within cubit, 
> unfortunately.  The complete remeshing case is interesting to me, but 
> that's not what I'm aimed at right now.


Its great! Yeah, a complete remesh is an entirely different story, but if 
you have a look in the documentation of FE_Field_Function, these two lines 

  in 
particular, you will be happy to find that this *might* not be too 
difficult to implement either.
 

> get cubit to export codimension 1 surfaces using its export commands.  The 
> output is always flattened in the sense that the z-coordinates of vertices 
> are stripped.  Perhaps your code snippet will help me by setting the 
> dimension to 3.  For now this works nicely, and cubit is slowly responding 
> to my email.
> As well, I choose ucd because GridIn::read_abaqus() doesn't like to find 
> that z-vertex from standard abaqus .inp files for codimension 1 surfaces, 
> but read_ucd() works as expected.)
>

I keep on forgetting that you're working in codim 1. Yes, 
GridIn::read_abaqus will definitely not cater for that case as it doesn't 
distinguish between dim and spacedim, but it might be an easy fix 

.
 

> I will try VectorTools::interpolate_to_different_mesh 
> 
>  
> when I get to my desk this morning.  I tried the FEFieldFunction 
> 
>  
> yesterday, but 
>
> FEFieldFunction > 
> FEFieldFunction(vector_dof_handler, euler_vector) 
>
> is very unhappy - it is not implemented for DoFHandlerType = 
> DoFHandler (and Mapping), rather it is 
> implemented for dim=spacedim problems only.  
>

I'm not sure if there's any specific reason as to why its only templatised 

 
and instantiated 

 for 
the codim 0 case, but its an enhancement that we could look into making. 
This class makes heavy use of the GridTools::find_cell_around_point 
function, and *perhaps* (pure speculation) it may not be sufficiently 
robust codim 1. Perhaps someone more knowledgable on the inner functioning 
/ use of this class would like to comment on this point?

Cheers,
J-P 

-- 
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: Apply Neumann Boundary condition

2016-12-01 Thread Jean-Paul Pelteret

Dear Benhour,

As I explained to someone else 

 
the day before yesterday, the point of this forum is not to provide a code 
review service without you having done due diligence on your side. Does 
this not work as expected? If this is the case, then how is the problem 
manifesting itself? Unless you have a specific issue pertaining to the code 
that you have posted then I'm afraid that there's no discussion to be had 
here.

Regards,
Jean-Paul

-- 
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] Apply Neumann Boundary condition

2016-12-01 Thread benhour . amirian66

Dear All,
I want to apply non-zero neumann boundary condition on the curved domain of 
half of the circle. The way that I define my geometry, the boundary id and 
apply the Neumann B.C is written as follow:

*Defining boundary id for different sections of domain (half_hyper_ball):*

const double tol_boundary = 1e-12
for (typename Triangulation ::active_cell_iterator
cell=triangulation.begin_active();
cell!=triangulation.end(); ++cell)
for (unsigned int face=0; faceface(face)->at_boundary() == true)
 {
   const Point face_center = cell->face(face)->center();
   if 
(std::abs(std::sqrt(face_center[0]*face_center[0]+face_center[1]*face_center[1])
  - radius) < tol_boundary)
  cell->face(face)->set_boundary_id (2); // faces on the outer 
curved edge of the domain...
   else
cell->face(face)->set_boundary_id (1);

*// Implying the mechanical boundary value to the curved surface of the 
domain that appears on the right hand side *

for (unsigned int face=0; faceface(face)->at_boundary() == true
  && cell->face(face)->boundary_id() == 2)
   {
scratch.fe_face_values_ref.reinit(cell, face);
for (unsigned int f_q_point=0; f_q_point neumann_value = eta_orderM * 
scratch.fe_face_values_ref.normal_vector(f_q_point);
  const unsigned int component_i = 
fe.system_to_component_index(i).first;
  const double JxW = scratch.fe_face_values_ref.JxW(f_q_point);
  data.cell_rhs(i) += neumann_value[component_i] * 
scratch.fe_face_values_ref.shape_value(i, f_q_point) * JxW;
 }
   }
 }
   }
It would be very kind of you if you let me know whether this definition for 
the Neumann boundary condition on the curved side of my domain is true or 
not.
Bests,
Benhour

-- 
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: Trouble building dealii with p4est - undeclared variables in scope

2016-12-01 Thread Bruno Turcksin

Chris,

On Thursday, December 1, 2016 at 10:56:13 AM UTC-5, Chris Coutinho wrote:
>
> With only p4est enabled, and P4EST_DIR pointing to the DEBUG folder of 
> version 0.3.4.1, I get the following errors associated with undeclared 
> variables in scope. The rest of the output can be found in the attached 
> make.log:
>
> I haven't used the script in a while but I don't think it's necessary to 
point to the DEBUG folder. 

>
>
> > ./p4est-setup-dealii.sh p4est-0.3.4.1.tar.gz /home/redclient04/Software/
> p4est/p4est-0.3.4.1
> > export P4EST_DIR=/home/redclient04/Software/p4est/p4est-0.3.4.1/DEBUG
>
> Can you try export P4EST_DIR=/home/redclient04/Software/p4est/p4est-0.3.
4.1

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] Trouble building dealii with p4est - undeclared variables in scope

2016-12-01 Thread Chris Coutinho

Hello deal.ii users,

I'm having trouble building dealii 8.4.2 with p4est support on OpenSUSE 
Leap 42.2, kernel 4.4.27-2-default, gcc/g++/gfortran version 4.8.5, openmpi 
1.10.3 (MPI 3.0)

I have successfully built deal.ii with MPI, PETSC, and METIS support and 
ran a few examples without a problem. Then I noticed that for few of the 
example problems, Trilinos and/or p4est also required, so I built version 
12.10.1 of Trilinos from source as well as versions 0.3.4.1 - 1.1 of p4est 
using the steps contained in the deal.ii README which worked fine - now the 
problem is building deal.ii

I used the following command successfully to build dealii (note Trilinos 
and p4est are OFF)

> rm -rf * && \
cmake \
-DDEAL_II_WITH_MPI:BOOL=ON \
-DDEAL_II_WITH_PETSC:BOOL=ON \
-DDEAL_II_WITH_TRILINOS:BOOL=ON \
-DDEAL_II_WITH_METIS:BOOL=ON \
-DDEAL_II_WITH_P4EST:BOOL=OFF \
-DCMAKE_INSTALL_PREFIX:FILEPATH=/home/redclient04/Software/INSTALL \
.. 2>&1 | tee cmake.log && \
make -j20 2>&1 | tee make.log && \
make test 2>&1 | tee test.log


With only p4est enabled, and P4EST_DIR pointing to the DEBUG folder of 
version 0.3.4.1, I get the following errors associated with undeclared 
variables in scope. The rest of the output can be found in the attached 
make.log:


.
.
[ 32%] Building CXX object source/fe/CMakeFiles/obj_fe.debug.dir/fe.cc.o
/home/redclient04/Software/dealii/source/distributed/tria.cc:302:9: error: 
‘p4est_connectivity_join_faces’ was not declared in this scope
   = p4est_connectivity_join_faces;
 ^
/home/redclient04/Software/dealii/source/distributed/tria.cc:677:9: error: 
‘p8est_connectivity_join_faces’ was not declared in this scope
   = p8est_connectivity_join_faces;
 ^
.
.

There seems to be an error in how I installed p4est, but I just downloaded 
the released tarballs and used the dealii script (link 
) to install 
it on my system. I tried building deal with p4est versions 0.3.4.1 - 1.1. 
Although some were more verbose than others, they all gave more or less the 
same error - some variable not being declared in the scope. Specifically, 
the command I used to build p4est 0.3.4.1 is:

> ./p4est-setup-dealii.sh p4est-0.3.4.1.tar.gz /home/redclient04/Software/
p4est/p4est-0.3.4.1
> export P4EST_DIR=/home/redclient04/Software/p4est/p4est-0.3.4.1/DEBUG


Can anyone give me an idea of what may have gone wrong in my workflow?

A quick rundown of what cmake was able to put together can be see in this 
summary. A more detailed output of cmake is attached as cmake.log

###
#
#  deal.II configuration:
#CMAKE_BUILD_TYPE:   DebugRelease
#BUILD_SHARED_LIBS:  ON
#CMAKE_INSTALL_PREFIX:   /home/redclient04/Software/INSTALL
#CMAKE_SOURCE_DIR:   /home/redclient04/Software/dealii
#(version 8.4.2, shortrev 0752c81)
#CMAKE_BINARY_DIR:   /home/redclient04/Software/dealii/build5
#CMAKE_CXX_COMPILER: GNU 4.8.5 on platform Linux x86_64
#/usr/bin/c++
#
#  Configured Features (DEAL_II_ALLOW_BUNDLED = ON, 
DEAL_II_ALLOW_AUTODETECTION = ON):
#  ( DEAL_II_WITH_64BIT_INDICES = OFF )
#DEAL_II_WITH_ARPACK set up with external dependencies
#DEAL_II_WITH_BOOST set up with external dependencies
#DEAL_II_WITH_BZIP2 set up with external dependencies
#DEAL_II_WITH_CXX11 = ON
#  ( DEAL_II_WITH_CXX14 = OFF )
#DEAL_II_WITH_HDF5 set up with external dependencies
#DEAL_II_WITH_LAPACK set up with external dependencies
#DEAL_II_WITH_METIS set up with external dependencies
#DEAL_II_WITH_MPI set up with external dependencies
#DEAL_II_WITH_MUPARSER set up with external dependencies
#DEAL_II_WITH_NETCDF set up with external dependencies
#  ( DEAL_II_WITH_OPENCASCADE = OFF )
#DEAL_II_WITH_P4EST set up with external dependencies
#DEAL_II_WITH_PETSC set up with external dependencies
#  ( DEAL_II_WITH_SLEPC = OFF )
#DEAL_II_WITH_THREADS set up with external dependencies
#DEAL_II_WITH_TRILINOS set up with external dependencies
#DEAL_II_WITH_UMFPACK set up with external dependencies
#DEAL_II_WITH_ZLIB set up with external dependencies
#
#  Component configuration:
#  ( DEAL_II_COMPONENT_DOCUMENTATION = OFF )
#DEAL_II_COMPONENT_EXAMPLES
#  ( DEAL_II_COMPONENT_PACKAGE = OFF )
#  ( DEAL_II_COMPONENT_PARAMETER_GUI = OFF )
#
#  Detailed information (compiler flags, feature configuration) can be 
found in detailed.log
#
#  Run  $ make info  to print a help message with a list of top level 
targets
#
###


Any advice would be much appreciated.

Cheers,
Chris





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

Re: [deal.II] Wall time vs number of cores for MPI run

2016-12-01 Thread Wolfgang Bangerth




I wrote a code using deal.II. Now, I want to compare effect of the number of
cores on the simulation time. The code is developed based on step-42 from
deal.II tutorial.

The code is executed in Ubuntu 14.04, Intel core i5 and 4GB ram as,

mpirun –n  ./code parameter_file.prm

The obtained results for 1, 2 and 4 cores is,

Number of cores | Total wall clock time

1  |   1.22s

2  |   0.90s

4  |   0.93s


Why the wall clock time for 4 cores is greater than the one obtained with 2 
cores.


I also executed step-42 (Just 2 cycles)  and the same pattern is observed,

Number of cores | Total wall clock time

1  |   4.73s

2  |   4.13s

4  |   5.89s


There are multiple possibilities:

* The problem is too small. If you split it into too many chunks, then each 
process does not have enough time to work, and all time is spent on 
communication. Because you have more communication if you have more 
processors, things actually take longer. Solution: Make the problem larger.


* You don't actually have four independent processors. For example, it could 
be that your i5 really only has two cores, each of which can execute two 
threads concurrently. But these two threads compete for resources, and so 
using 4 threads is not faster than using 2 threads (= 2 processes).


Other possibilities come to mind as well, but these I would investigate.

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] Wall time vs number of cores for MPI run

2016-12-01 Thread dealii . group



Dear all

 

I wrote a code using deal.II. Now, I want to compare effect of the number 
of cores on the simulation time. The code is developed based on step-42 
from deal.II tutorial. 

The code is executed in Ubuntu 14.04, Intel core i5 and 4GB ram as,

mpirun –n  ./code parameter_file.prm 

The obtained results for 1, 2 and 4 cores is,

Number of cores | Total wall clock time 

1  |   1.22s

2  |   0.90s

4  |   0.93s


Why the wall clock time for 4 cores is greater than the one obtained with 2 
cores.


I also executed step-42 (Just 2 cycles)  and the same pattern is observed,

Number of cores | Total wall clock time 

1  |   4.73s

2  |   4.13s

4  |   5.89s


 

Best

Pasha

-- 
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: deal.ii and Reduced Basis method

2016-12-01 Thread Giulia Deolmi

Dear Jean-Paul and Wolfgang,
thanks a lot for your replies! We contacted the developers of pyMOR who 
will help us to solve the RB problem, using deal.ii as an external software.
Kind regards,
Giulia

Il giorno giovedì 1 dicembre 2016 13:07:58 UTC+1, Wolfgang Bangerth ha 
scritto:
>
>
> Giulia, 
> there are also this thesis 
>https://vtechworks.lib.vt.edu/handle/10919/52960 
> and the pyMOR package has deal.II interfaces: 
>http://pymor.org/ 
>
> Best 
>   W. 
>
>
> On 12/01/2016 01:05 AM, Jean-Paul Pelteret wrote: 
> > Dear Giulia, 
> > 
> > Judging by the lack of reply it seems that no-one knows of (or has 
> > implemented) an open-source library to specifically do model order 
> reduction 
> > with deal.II. However, at least one of my colleagues uses deal.II to 
> perform 
> > ROM via proper orthogonal decomposition, so deal.II definitely provides 
> all of 
> > the core functionality to implement this yourself. If its of any use to 
> you, 
> > here's a link to his paper (sadly during final editing his text citing 
> deal.II 
> > got removed without him noticing): 
> > http://onlinelibrary.wiley.com/doi/10.1002/gamm.201610011/full 
> > 
> > Regards, 
> > J-P 
> > 
> > On Monday, November 14, 2016 at 11:03:16 AM UTC+1, Giulia Deolmi wrote: 
> > 
> > Dear all, 
> > I have implemented a parameter dependent problem in deal.ii and now 
> I 
> > would like to apply the Reduced Basis (RB) method to it. 
> > Do you know if there is already some code available that I can use 
> where 
> > the RB has already been implemented (in deal.ii or compatible to 
> it)? 
> > So far I have only found a software called pyMOR for the RB method 
> > (http://pymor.org/). In theory it should be possible to use deal.ii 
> as an 
> > external software. The example that is given is not so clear to me, 
> > though. Is anyone familiar with it? 
> > Thanks a lot in advance, 
> > Kind regards, 
> > Giulia Deolmi 
> > 
> > -- 
> > 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+un...@googlegroups.com  
> > . 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [deal.II] Re: mesh quality during deformations using MappingQEulerian

2016-12-01 Thread thomas stephens

> Its great that you're getting somewhere with this!
>
> J-P, you (and the entire dealii community) are a paragon of encouragement,
and I appreciate that very much.

After I wrote you yesterday I was able to figure out how to 'play a journal
file' from within an embedded python session within dealii, so my problem

  (exporting from cubit is actually a bit of a problem, I have submitted a
> service email to them - but if I do this through the gui it all works)
>

is no longer a problem.  Thank you for your code snippet, and here's what I
came up with yesterday: (this is from within my dealii code)


  // taken from: http://stackoverflow.com/questions/12142174/run-a-
python-script-with-arguments

  char export_script[50];
  char export_filename[150];
  sprintf(export_script,   "export_codim_1_to_ucd.py");
  sprintf(export_filename, "/home/tds3/com/biomembranes/
scratch/mesh_modification/cubit_strategy/data/smoothed_from_cubit.ucd");

  FILE *file;
  file = fopen(export_script, "r");
  size_t argc = 2;
  char *argv[argc];
  argv[0] = export_script;
  argv[1] = export_filename;

  // all this junk requires Python version < 3.0
  // because PySys_SetArgv() does not like the char* to wchar_t* conversion
of argv
  Py_SetProgramName(argv[0]);
  Py_Initialize();

  PyRun_SimpleString("import cubit, sys\n"
 "cubit.init('')\n"
 "print('cubit imported')\n"
 "cubit.cmd(\"import abaqus mesh geometry
'./data/abaqus_test.inp'\")\n"
 "cubit.cmd(\"smooth surface all laplace\")\n"
);
  PySys_SetArgv(argc,argv);
  PyRun_SimpleFile(file, export_script);

  Py_Finalize();

(As a quick aside - I call this export script because I can't get cubit to
export codimension 1 surfaces using its export commands.  The output is
always flattened in the sense that the z-coordinates of vertices are
stripped.  Perhaps your code snippet will help me by setting the dimension
to 3.  For now this works nicely, and cubit is slowly responding to my
email.
As well, I choose ucd because GridIn::read_abaqus() doesn't like to find
that z-vertex from standard abaqus .inp files for codimension 1 surfaces,
but read_ucd() works as expected.)


2. A function that actually
>> 
>> moves
>> 
>> the triangulation vertices for you based on this vector.
>>
>
> At this point the Triangulation attached to my GridIn object is the new
> triangulation, so this may not be a problem.
>


> Ok, so this might be a point of difficulty. See the answer to your next
> question...
>

>
>> 3. A function that would interpolate the optimal Q1 Euler vector onto a
>> given FE space, which would presumably represent the displacement solution
>> to some other problem.
>>
>>
> *Here's where my question for you comes in:*  At this stage I have a new
>> Triangulation (call it temp_triangulation) which holds my optimal
>> vertices.  The vertices in temp_triangulation live on some surface in real
>> space.  I have my original Triangulation (call it orig_triangulation) which
>> satisfies orig_triangulation.n_vertices() ==
>> temp_triangulation.n_vertices().  *How to I obtain a new euler_vector of
>> size dof_handler.n_dofs() at this stage? *
>> I have done the following so far:
>>
>1   /* update euler_vector to describe smoothed mesh */
>2   FESystem vertex_fe(FE_Q(1), spacedim);
>3   DoFHandler vertex_dof_handler(temp_triangulation);
>4   vertex_dof_handler.distribute_dofs(vertex_fe);
>5   Vector vertex_euler_vector(vertex_dof_handler.n_dofs());
>6
>7   std::vector original_vertices =
> triangulation.get_vertices();
>8   std::vector vertex_touched(temp_triangulat
> ion.n_vertices(),false);
>9
>   10   typename DoFHandler::active_cell_iterator
>   11 cell=vertex_dof_handler.begin_active(),
>   12 endc=vertex_dof_handler.end();
>   13   for (; cell!=endc; ++cell)
>   14 for (unsigned int v=0; v < 4; ++v)
>
>
By "4", you mean GeometryInfo::vertices_per_cell, right?
>

YES! Sloppy coding on my part


>   15   if (!vertex_touched[cell->vertex_index(v)])
>>   16   {
>>   17 for (unsigned int k=0; k>   18 {
>>   19   vertex_euler_vector(cell->vertex_dof_index(v,k))
>>   20 = cell->vertex(v)(k) - original_vertices[cell->vertex
>> _index(v)](k);
>>   21 }
>>   22 vertex_touched[cell->vertex_index(v)] = true;
>>   23
>>
>>
>
At first glance this looks ok. My biggest concern is that you've assumed
> that your old and new triangulations have the same vertex ordering. I'm
> inclined to think that this is ok because I don't think that Cubit
> renumbers mesh entities unless you ask it to, and nor does deal.II. But you
> should probably

Re: [deal.II] Re: deal.ii and Reduced Basis method

2016-12-01 Thread Wolfgang Bangerth



Giulia,
there are also this thesis
  https://vtechworks.lib.vt.edu/handle/10919/52960
and the pyMOR package has deal.II interfaces:
  http://pymor.org/

Best
 W.


On 12/01/2016 01:05 AM, Jean-Paul Pelteret wrote:

Dear Giulia,

Judging by the lack of reply it seems that no-one knows of (or has
implemented) an open-source library to specifically do model order reduction
with deal.II. However, at least one of my colleagues uses deal.II to perform
ROM via proper orthogonal decomposition, so deal.II definitely provides all of
the core functionality to implement this yourself. If its of any use to you,
here's a link to his paper (sadly during final editing his text citing deal.II
got removed without him noticing):
http://onlinelibrary.wiley.com/doi/10.1002/gamm.201610011/full

Regards,
J-P

On Monday, November 14, 2016 at 11:03:16 AM UTC+1, Giulia Deolmi wrote:

Dear all,
I have implemented a parameter dependent problem in deal.ii and now I
would like to apply the Reduced Basis (RB) method to it.
Do you know if there is already some code available that I can use where
the RB has already been implemented (in deal.ii or compatible to it)?
So far I have only found a software called pyMOR for the RB method
(http://pymor.org/). In theory it should be possible to use deal.ii as an
external software. The example that is given is not so clear to me,
though. Is anyone familiar with it?
Thanks a lot in advance,
Kind regards,
Giulia Deolmi

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



--

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: deal.ii and Reduced Basis method

2016-12-01 Thread Jean-Paul Pelteret

Dear Giulia,

Judging by the lack of reply it seems that no-one knows of (or has 
implemented) an open-source library to specifically do model order 
reduction with deal.II. However, at least one of my colleagues uses deal.II 
to perform ROM via proper orthogonal decomposition, so deal.II definitely 
provides all of the core functionality to implement this yourself. If its 
of any use to you, here's a link to his paper (sadly during final editing 
his text citing deal.II got removed without him noticing):
http://onlinelibrary.wiley.com/doi/10.1002/gamm.201610011/full

Regards,
J-P

On Monday, November 14, 2016 at 11:03:16 AM UTC+1, Giulia Deolmi wrote:
>
> Dear all,
> I have implemented a parameter dependent problem in deal.ii and now I 
> would like to apply the Reduced Basis (RB) method to it. 
> Do you know if there is already some code available that I can use where 
> the RB has already been implemented (in deal.ii or compatible to it)? 
> So far I have only found a software called pyMOR for the RB method (
> http://pymor.org/). In theory it should be possible to use deal.ii as an 
> external software. The example that is given is not so clear to me, though. 
> Is anyone familiar with it?
> Thanks a lot in advance,
> Kind regards,
> Giulia Deolmi
>

-- 
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: Apply Neumann Boundary condition

[deal.II] Re: Apply Neumann Boundary condition

[dealii-developers] Promoting developer version documentation in search engines and user forum posts

Re: [deal.II] Re: mesh quality during deformations using MappingQEulerian

[deal.II] Re: Apply Neumann Boundary condition

[deal.II] Apply Neumann Boundary condition

[deal.II] Re: Trouble building dealii with p4est - undeclared variables in scope

[deal.II] Trouble building dealii with p4est - undeclared variables in scope

Re: [deal.II] Wall time vs number of cores for MPI run

[deal.II] Wall time vs number of cores for MPI run

Re: [deal.II] Re: deal.ii and Reduced Basis method

Re: [deal.II] Re: mesh quality during deformations using MappingQEulerian

Re: [deal.II] Re: deal.ii and Reduced Basis method

[deal.II] Re: deal.ii and Reduced Basis method

14 matches

Site Navigation

Mail list logo

Footer information