[deal.II] Classical returning mapping algorithm for plasticity in deal.ii

2020-09-29 Thread Muhammad Mashhood
Dear fellow community members,
 Hi! I want to 
simulate some simulation cases based upon the elastoplastic material model. 
They involve the loading and then unloading of the material too. I tried 
with the step-42 but apparently it is for contact based problem involving 
only the loading of material so unfortunately I cannot use it completely 
for my application.
Therefore I am looking for some code in deal.ii which has classical return 
mapping plasticity algorithm. I already looked in code gallery and 
publications but so far couldn't find one. I will be grateful if someone 
recently worked on it or something similar and can direct me to the source. 
Thank you in advance for cooperation!

*Best regards,*
Muhammad   

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/bad80739-3031-4d29-93d7-45a42bab8aa9n%40googlegroups.com.


Re: [deal.II] Output of Gauss point stress tensor

2020-09-29 Thread Muhammad Mashhood
Thanks a lot Prof. Wolfgang. Your guidance was very fruitful and right on 
point. Solved my problem! :)

On Thursday, August 6, 2020 at 1:53:48 AM UTC+2 Wolfgang Bangerth wrote:

>
> >  Thanks for the guidance. I tried 
> > replacing the " source/particles/particle_handler.cc 
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10589%2Ffiles%23diff-df7869b8ff6741c5bba620988f7bd995=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595=CQSVVYYrHp5wMfy3INtkJBdS%2BNjFzBqLAdPwVHI1r%2FU%3D=0>"
>  
>
> > file with the one present in 
> > "https://github.com/dealii/dealii/pull/10589/files;. Also 
> > include/deal.II/particles/particle_accessor.h 
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10319%2Ffiles%23diff-ba98c140727c3e55b479f34172de381b=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595=Y9F5eICnrFT8jNpnmg03tO3gb%2BWO%2B8xEqt9%2F9fucTBQ%3D=0>
>  
>
> > and source/particles/particle_accessor.cc 
> > <
> https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fdealii%2Fdealii%2Fpull%2F10319%2Ffiles%23diff-0b2cb32ab20618cd2a77e2ddfda9eddd=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138647592=7ZHhT3M4M%2Bu2FaPwpR2qwSkJevjIip4d7%2BvaQrqmsG0%3D=0>
>  
>
> > from "https://github.com/dealii/dealii/pull/10319/files;. Then compiled 
> again 
> > my deal.ii 9.2.0 but it gives error during compilation.
>
> Yes -- we put about 10 changes every day into deal.II. You can't just 
> replace 
> individual files in 9.2 with the current development sources :-)
>
>
> > Therefore as a second option, I have created a simplified code which 
> > represents my problem. Kindly receive the files attached. Looking 
> forward for 
> > your guiding response!
>
> The code in question looks like this:
>
> Particles::Particle new_particle;
> new_particle.set_location(location);
> new_particle.set_reference_location(
> mapping.transform_real_to_unit_cell(cell, location));
> new_particle.set_id(next_unused_particle_id);
>
> SymmetricTensor<2, dim> strain; strain = 0;
> new_particle.set_properties(make_array_view(strain));
>
> particle_handler.insert_particle(new_particle, cell);
>
> It is correct that set_properties() throws an exception here, because 
> there 
> really is no property pool associated with this particle. If you write it 
> like 
> this:
>
> auto inserted_particle
> = particle_handler.insert_particle(new_particle, cell);
> inserted_particle->set_properties(make_array_view(strain));
>
> then things will work if you also change the number of properties stored 
> by 
> the ParticleHandler object to dim*(dim+1)/2=6 (it is currently 'dim').
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/e348da76-8604-4b16-a599-a208e38d1e23n%40googlegroups.com.


Re: [deal.II] Output of Gauss point stress tensor

2020-08-05 Thread Muhammad Mashhood
Dear Prof. Wolfgang,
 Thanks for the guidance. I tried 
replacing the " source/particles/particle_handler.cc 
<https://github.com/dealii/dealii/pull/10589/files#diff-df7869b8ff6741c5bba620988f7bd995>"
 
file with the one present in 
"https://github.com/dealii/dealii/pull/10589/files;. Also 
include/deal.II/particles/particle_accessor.h 
<https://github.com/dealii/dealii/pull/10319/files#diff-ba98c140727c3e55b479f34172de381b>
 
and source/particles/particle_accessor.cc 
<https://github.com/dealii/dealii/pull/10319/files#diff-0b2cb32ab20618cd2a77e2ddfda9eddd>
 
from "https://github.com/dealii/dealii/pull/10319/files;. Then compiled 
again my deal.ii 9.2.0 but it gives error during compilation.

Therefore as a second option, I have created a simplified code which 
represents my problem. Kindly receive the files attached. Looking forward 
for your guiding response!
Thank you very much for ongoing cooperation.

Best regards,
Muhammad Mashhood 

On Friday, July 31, 2020 at 5:31:13 PM UTC+2 Wolfgang Bangerth wrote:

> On 7/30/20 5:26 PM, Muhammad Mashhood wrote:
> > 
> > _But it gives the following error on running:_
> > 
> > /An error occurred in line <298> of file 
> >  in 
> function
> > void dealii::Particles::Particle spacedim>::set_properties(const 
> > dealii::ArrayView&) [with int dim = 3; int spacedim = 3]
> > The violated condition was:
> > property_pool != nullptr
> > Additional information:
> > [...]
>
> > I explored the mailing list and found someone from the community already 
> had 
> > similar problem of assigning the properties to the particles where it 
> was 
> > suggested to use following way of assigning the properties:
>
> I believe that this is a bug that I fixed a while back:
> https://github.com/dealii/dealii/pull/10589
> https://github.com/dealii/dealii/issues/10590
> Unfortunately, this happened after the 9.2 release. Are you in a position 
> to 
> work with the current development sources?
>
> If this doesn't solve the problem, can you come up with a simplified piece 
> of 
> code that illustrates the issue?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/dc35abbf-ee56-4917-863b-222199337b76n%40googlegroups.com.


3d_block.msh
Description: Mesh model
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 


#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 



#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 

// For particles handling and data output
#include 
#include 
#include 



#include 
#include 
#include 
#include 
#include 



using namespace dealii;

int main ()
{


/
// Varible declaration and initializations //
/
const int dim = 3;

Triangulation triangulation;
MappingQ mapping(1);
Particles::ParticleHandler particle_handler(triangulation, mapping, /*n_properties=*/dim);
types::particle_index   next_unused_particle_id;

const unsigned int fe_degree = 1;

FESystem  fe(FE_Q(QGaussLobatto<1>(fe_degree+1)), dim);
const QGauss  quadrature_formula(fe_degree + 1);




// Reading mesh file //
//

GridIn gridin;
gridin.attach_triangulation(triangulation);
std::ifstream f("3d_block.msh");
gridin.read_msh(f);

std::cout << "Number of active cells after make_grid():   "
<< triangulation.n_active_cells()
<< std::endl;

//
// Distribution of dofs to the dof handler //
/

DoFHandlerdof_handler(triangulation);
dof_handler.distribute_dofs(fe);



/
// creating particles and assigning values for quadrature poi

Re: [deal.II] Output of Gauss point stress tensor

2020-07-30 Thread Muhammad Mashhood
dParticleQuantities.begin()+ part*ncomponents, 
interpolatedParticleQuantities.begin()+ part*ncomponents + ncomponents)); *

If I have related it correctly to my case, I also then tried the similar 
way e.g.
   

*new_particle.set_properties(make_array_view(total_strain.begin_raw(),total_strain.end_raw()));*

instead of *new_particle.set_properties(make_array_view(total_strain));* 

It still stops with the same (2nd) error as mentioned above. Is there 
another way of doing it or am I not using the correct approach as per my 
limited knowledge so far? Sorry for the lengthy thread, I wanted to clear 
out the approaches which I tried so far as much as possible.

Thank you very much for your ongoing and productive support.

Regards,
Muhammad  
On Thursday, July 30, 2020 at 2:11:10 AM UTC+2 Wolfgang Bangerth wrote:

> On 7/28/20 11:05 AM, Muhammad Mashhood wrote:
> > 
> > /.~/working_dir/step-42$ /step-42 p1_chinese.prm
> > Segmentation fault (core dumped)/
> > 
> > I tried to comment out the line "  , particle_handler(triangulation, 
> mapping, 
> > /*n_properties=*/dim) " and by doing so the code starts running normally.
> > 
> > I have tried to run it in the debug mode but over there the program 
> exits with 
> > following error:
> > 
> > /(gdb) r
> > Starting program: ~/working_dir/step-42/step-42
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library 
> "/lib/x86_64-linux-gnu/libthread_db.so.1".
> > *** Call this program as <./step-42 input.prm>
>
> You need to run the executable with
> r p1_chinese.prm
> to make sure it loads the appropriate input file, or you will not see the 
> segmentation fault in the debugger.
>
>
> > [Inferior 1 (process 5082) exited with code 01]/
> > 
> > Can there be a possible problem in using the " 
> > /particle_handler(triangulation, mapping, /*n_properties=*/dim) /" ? 
> Thank you!
>
> I don't know. Can you get a backtrace in the debugger?
>
> It's something that ought to work. If you can't figure out what is 
> happening, 
> send me the exact .cc file you're trying to run and I'll take a look!
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/80201761-2857-489e-9ac8-17f1471ac877n%40googlegroups.com.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-28 Thread Muhammad Mashhood
Dear Prof. Wolfgang,
  Thank you very much for the 
suggestions. To have a quick solution, I am opting the first suggestion 
i.e. to make particles on quadrature points and assigning them the tensor 
quantities. And if I gain some reasonable results specific to my project 
then I might also want to add it as a permanent feature in my code by 
spending more time to implement the second suggested solution of elegant 
way. So I have updated my version from 9.1.1 to 9.2.0 and started writing 
the code for particles. 

My original code is similar as step-42 but first I am using step-42 to 
fulfill at least the task of creating particles on quadrature point 
locations. 

I have declared the concerned variables:



*Particles::ParticleHandler particle_handler;
types::particle_index   next_unused_particle_id;*
*MappingQ mapping;*

and then added the following syntax during construction of  class (
*PlasticityContactProblem::PlasticityContactProblem*) (after line 833):



*, mapping(1), particle_handler(triangulation, mapping, 
/*n_properties=*/dim), next_unused_particle_id(0)*

When I run the step-42 then it returns following error:


*.~/working_dir/step-42$ /step-42 p1_chinese.prmSegmentation fault (core 
dumped)*

I tried to comment out the line "  , particle_handler(triangulation, 
mapping, /*n_properties=*/dim) " and by doing so the code starts running 
normally. 

I have tried to run it in the debug mode but over there the program exits 
with following error:






*(gdb) rStarting program: ~/working_dir/step-42/step-42 [Thread debugging 
using libthread_db enabled]Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".*** Call this program as 
<./step-42 input.prm>[Inferior 1 (process 5082) exited with code 01]*

Can there be a possible problem in using the " *particle_handler(triangulation, 
mapping, /*n_properties=*/dim) *" ? Thank you!
On Friday, July 17, 2020 at 1:35:53 AM UTC+2 Wolfgang Bangerth wrote:

> On 7/16/20 9:15 AM, Muhammad Mashhood wrote:
> > So far it would be enough if I have the Gauss point values only at the 
> points 
> > rather than having complete field. I like to access these point values 
> of 
> > stress and strain tensors in .vtk file or .pvtu file through ParaView 
> (same as 
> > I am accessing the results currently).
> > I would be grateful if you or any other user has experience in this 
> regard or 
> > know about relevant deal.ii tutorial dealing with same feature.
>
> deal.II has functionality to output data on individual points if that data 
> is 
> associated with particles. I don't know how much work you want to invest 
> in 
> getting this to work for you, but here are two options:
>
> * Easy: Create a ParticleHandler object, loop over all of your quadrature 
> points, and for each quadrature point you create a particle. You can then 
> associate "properties" with each particle, and use Particles::DataOut to 
> output these properties in the same way as you would use DataOut for field 
> data. You can probably figure out how this works by looking at the draft 
> step-19 tutorial program:
> https://github.com/dealii/dealii/pull/10301
>
> * More work, but more elegant: You could write a class, let's say 
> QuadraturePointData::DataOut or something similar, to which you could 
> describe 
> the information of location + values without the detour of particles. I'm 
> sure 
> we'd be happy to walk you through the process of doing so if you wanted to 
> go 
> for that, and it would be a very nice addition to deal.II if you wanted to 
> get 
> it merged.
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/d3dbe6ca-cf2a-4126-95d7-4a36001e4430n%40googlegroups.com.


Re: [deal.II] Output of Gauss point stress tensor

2020-07-16 Thread Muhammad Mashhood
Dear Prof. Wolfgang,
  Thank you for the comprehensive and 
informative response. As my goal is to access the original Gauss point 
values and I do not want to involve any interpolation or approximation 
scheme so I would like to opt for the first option among the two you 
mentioned:


*"If you want to output the stress/strain information, you have two 
options: * 






** You actually do show them as values defined only at individual points, 
rather than as fields. In this scheme, the stress/strain really only exists 
at the quadrature points, but not anywhere in between. You can't create 
surface plots, you can't create isocontour plots, etc. * You create a field 
that somehow approximates these point values. There are different ways of 
doing that, and the approach you are currently using is one way for this."*
 
So far it would be enough if I have the Gauss point values only at the 
points rather than having complete field. I like to access these point 
values of stress and strain tensors in .vtk file or .pvtu file through 
ParaView (same as I am accessing the results currently). 
I would be grateful if you or any other user has experience in this regard 
or know about relevant deal.ii tutorial dealing with same feature. Thank 
you!
On Thursday, July 16, 2020 at 4:59:31 AM UTC+2 Wolfgang Bangerth wrote:

> On 7/15/20 11:05 AM, Muhammad Mashhood wrote:
> > 
> > My question is that along with this, can I also export the stress and 
> strain 
> > tensors data of quadrature points i.e. 
> > "local_history_strain_values_at_qpoints[i][j]" directly to the output 
> file 
> > (.pvtu or .vtu etc.) i.e. without mapping or averaging etc. on the node. 
> In 
> > this way I want to directly visualize the quadrature point values of 
> stress 
> > and strain in Paraview.
>
> The question is more a philosophical one than one of how you can achieve 
> this. 
> Typically, when we output information in finite element contexts, we 
> output 
> them as "fields", i.e., functions of space. This allows us to show them as 
> surfaces, with color gradients, etc. The strategy you have found of taking 
> values defined in (quadrature) points and converting them to fields is a 
> way 
> to make that happen.
>
> If you want to output the stress/strain information, you have two options:
>
> * You actually do show them as values defined only at individual points,
> rather than as fields. In this scheme, the stress/strain really only exists
> at the quadrature points, but not anywhere in between. You can't create
> surface plots, you can't create isocontour plots, etc.
> * You create a field that somehow approximates these point values. There 
> are
> different ways of doing that, and the approach you are currently using is
> one way for this.
>
> So the question is mostly: What's your goal with this? Do you want to show 
> these quantities as fields, or as data to be visualized at individual 
> points?
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/bc35a6d4-f3d2-4c57-a193-b26afb6aaa5dn%40googlegroups.com.


[deal.II] Output of Gauss point stress tensor

2020-07-15 Thread Muhammad Mashhood

Dear Deal.ii users,
Hi! I am working on the deal.ii code. I 
have data of stress and strain tensors at quadrature points. Currently 
using the results_output function, I am transferring the data at nodal 
points of my triangulation using " qpoint_to_dof_matrix.vmult " function 
and mapping "local_history_strain_values_at_qpoints[i][j]" Gauss point 
values on the "history_strain_field[i][j]" tensor with 
"dg_cell->set_dof_values" function. After this I write this nodal values 
data "history_strain_field[i][j]" as .pvtu and .vtu files for Paraview.

My question is that along with this, can I also export the stress and 
strain tensors data of quadrature points i.e. 
"local_history_strain_values_at_qpoints[i][j]" directly to the output file 
(.pvtu or .vtu etc.) i.e. without mapping or averaging etc. on the node. In 
this way I want to directly visualize the quadrature point values of stress 
and strain in Paraview.



*My current simplified code is following:*

FE_DGQ history_fe (1);
DoFHandler history_dof_handler (triangulation);
history_dof_handler.distribute_dofs (history_fe);

std::vector< std::vector< Vector > >
history_strain_field (dim, std::vector< Vector >(dim)),
 local_history_strain_values_at_qpoints (dim, 
std::vector< Vector >(dim)),
 local_history_strain_fe_values (dim, std::vector< 
Vector >(dim));


history_strain_field[i][j].reinit(history_dof_handler.n_dofs());

local_history_strain_values_at_qpoints[i][j].reinit(quadrature_formula.size());

local_history_strain_fe_values[i][j].reinit(history_fe.dofs_per_cell);



for (unsigned int q=0; qset_dof_values 
(local_history_strain_fe_values[i][j],
 
history_strain_field[i][j]); 
}

DataOut  data_out;
  data_out.attach_dof_handler (history_dof_handler);


  //for strain
  data_out.add_data_vector (history_strain_field[0][0], 
"strain_xx");
  data_out.add_data_vector (history_strain_field[1][1], 
"strain_yy");
  data_out.add_data_vector (history_strain_field[0][1], 
"strain_xy");

data_out.build_patches ();


  const std::string filename_base_strain = ("strain-" + 
filename_base);



  const std::string filename =
  (output_dir + filename_base_strain + "-"
   + 
Utilities::int_to_string(triangulation.locally_owned_subdomain(), 4));

  std::ofstream output_vtu((filename + ".vtu").c_str());
  data_out.write_vtu(output_vtu);


  pcout << output_dir + filename_base_strain << ".pvtu" << 
std::endl;

  if (this_mpi_process == 0)
{
  std::vector filenames;
for (unsigned int i = 0; i < 
n_mpi_processes; ++i)

filenames.push_back(filename_base_strain + "-" +
  
Utilities::int_to_string(i, 4) +
  ".vtu");

std::ofstream 
pvtu_master_output((output_dir + filename_base_strain + ".pvtu").c_str());

data_out.write_pvtu_record(pvtu_master_output, filenames);

std::ofstream 
visit_master_output((output_dir + filename_base_strain + ".visit").c_str());

data_out.write_pvtu_record(visit_master_output, filenames);
}


}

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/cafe2213-2782-4307-bdee-5554a17d17bcn%40googlegroups.com.


Re: [deal.II] step-42 now available

2020-04-01 Thread Muhammad Mashhood
Hi Mac,
 I really appreciate your concern and thank you for nice and 
brief summary regarding classical plasticity algorithm. 
I would like to highlight here that in Prisms-plasticity this algorithm is 
also implemented but I checked with its continuum plasticity application, 
which so far is not updated and hence also the code is not working for 
continuum plasticity part. As per communication from developers they will 
update and make it run in next update.
Secondly I am preferably using the step-42. Personally for me it seems bit 
simpler and I already coupled it with other physics for multi-physics 
problem.


On Wednesday, April 1, 2020 at 11:26:44 AM UTC+2, mac wrote:
>
> Hi all 
>
> Classical plasticity is underpinned by return mapping algorithms that 
> operate at the level of the quadrature point. One has a global predictor 
> for the displacement field where we assume frozen plastic flow. Then at 
> each quadrature point you compute a trial strain, and hence a trial stress. 
> The trial stress is used to test for yield at the quadrature point. You 
> then compute the plastic multiplier, and hence the plastic strain, to 
> return to the yield surface. This is an iterative process at the global and 
> possibly local level.
>
No doubt, you are very right that the plastic multiplier is evaluated in 
iterative manner and this very plastic multiplier is then a key to plastic 
strain evaluation. But here I would like to highlight that in the step-42 
seemingly a bit different method is used to solve elastoplastic problem. As 
far as I could understand the algorithm in hand, here after evaluating the 
trial stress in terms of Von-Mises equivalent stress and also when it is 
higher than the yield stress, the stiffness tensor is evaluated as function 
of current trial stress. After that this very stiffness tensor is used to 
evaluate displacement and strain increments and convergence of Newton 
algorithm is checked. So in this way the system is solved iteratively and 
after convergence the displacement and the total strain is present as 
output. 
As the total strain is the output that is why I need here some way to 
evaluate the plastic and elastic strain (any one of them so that other can 
be evaluated from additive decomposition). If you want, you can check this 
interesting and simple algorithm in a deal.ii step-42 code or this nice 
article of "Goal oriented error estimation and mesh adaptivity in 3d 
elastoplasticity problems" doi: 
https://doi-org.proxy.bnl.lu/10.1007/s10704-016-0113-y 

I hope I explained it well. Thanks again for showing interest and your 
concern. 

>
> All of this can and has been done in deal.ii. Wolfgang has suggested using 
> CellDataStorage which will allow you to handle the quadrature point data. 
> For implementations have a look at 
> https://github.com/prisms-center/plasticity . 
>
> You might also want to have a look at some of the extensive literature 
> e.g. https://onlinelibrary.wiley.com/doi/book/10.1002/9780470694626 Here 
> they explain the algorithm in detail.
>
> Best
> A
>
> On 30 Mar 2020, at 19:09, Muhammad Mashhood  > wrote:
>
>
>
> On Monday, February 24, 2020 at 12:42:17 AM UTC+1, Wolfgang Bangerth wrote:
>>
>>
>> > In my question I meant whether is it possible to evaluated plastic 
>> strain 
>> > component from currently implemented plasticity algorithm as a further 
>> > development of this code? 
>>
>> I am pretty sure that it is, by just computing the difference between the 
>> elastic stress (C eps(u)) and the actual stress computed. In fact, for 
>> the 
>> current situation, the actual stress computed equal to the elastic stress 
>> where it is less than the yield stress (and so the plastic strain is 
>> zero), 
>> and it is simply a fraction of the elastic stress where it exceeds the 
>> yield 
>> stress. Once you have the plastic stress, you can compute the plastic 
>> strain 
>> by multiplying it by C^{-1}. 
>> Thank you very much Prof. Wolfgang for your suggestion and I hope you are 
>> doing all well. As far as I understood now from your suggestion is that on 
>> the base of additive decomposition, I can subtract elastic stress (C 
>> eps(u)) from the actual stress computed to have the plastic stress part. 
>> But here I just noticed in the program that we also need (eps(u)) or the 
>> elastic strain part to have elastic stress part's value when the domain is 
>> in the plastic region.
>
> In one dimension problem there is I think no problem because from 
> stress strain curve one knows already the elastic stress value (which is 
> yield stress) but here we have multidimensional problem i.e. stress and 
> strain as a 2nd order tensor. Therefore I am 

Re: [deal.II] Re: step-42 now available

2020-03-30 Thread Muhammad Mashhood


On Monday, February 24, 2020 at 12:42:17 AM UTC+1, Wolfgang Bangerth wrote:
>
>
> > In my question I meant whether is it possible to evaluated plastic 
> strain 
> > component from currently implemented plasticity algorithm as a further 
> > development of this code? 
>
> I am pretty sure that it is, by just computing the difference between the 
> elastic stress (C eps(u)) and the actual stress computed. In fact, for the 
> current situation, the actual stress computed equal to the elastic stress 
> where it is less than the yield stress (and so the plastic strain is 
> zero), 
> and it is simply a fraction of the elastic stress where it exceeds the 
> yield 
> stress. Once you have the plastic stress, you can compute the plastic 
> strain 
> by multiplying it by C^{-1}. 
> Thank you very much Prof. Wolfgang for your suggestion and I hope you are 
> doing all well. As far as I understood now from your suggestion is that on 
> the base of additive decomposition, I can subtract elastic stress (C 
> eps(u)) from the actual stress computed to have the plastic stress part. 
> But here I just noticed in the program that we also need (eps(u)) or the 
> elastic strain part to have elastic stress part's value when the domain is 
> in the plastic region.

In one dimension problem there is I think no problem because from 
stress strain curve one knows already the elastic stress value (which is 
yield stress) but here we have multidimensional problem i.e. stress and 
strain as a 2nd order tensor. Therefore I am thinking now that how this 
elastic strain tensor can be evaluated to have elastic stress part to be 
subtracted from total calculated stress. 
One of the idea I have so far is to use the calculated "strain_tensor" to 
find the elastic stress as  "elastic_stress_tensor = 
(stress_strain_tensor_kappa + stress_strain_tensor_mu) * strain_tensor". 
But again the point is that the "strain_tensor" here is the total strain 
rather than elastic strain component.  

Kindly correct me if I misunderstood your suggestion at any point or if 
there is an alternate approach possible. Thank you again in advance. 
Stay healthy stay safe!

>
>
> > Then as a step further I would be trying to store this plastic strain in 
> cells 
> > or Gauss points along with the modified yield strength (due to isotropic 
> > hardening) so that history of loading is stored too in the domain. 
>
> I imagine that that, too, can be done. I'm not an expert in plasticity, 
> but I 
> see no fundamental reasons why what you want to do should not be possible. 
> There are also classes CellDataStorage and TransferableQuadraturePointData 
> and 
> parallel::distributed::ContinuousQuadratureDataTransfer that can help you 
> with 
> storing information at quadrature points. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/9a59d3e4-e11d-4f6e-af92-c34c85fe9b57%40googlegroups.com.


Re: [deal.II] Re: step-42 now available

2020-02-21 Thread Muhammad Mashhood
Thank you for the response Prof. Wolfgang. My apology for the confusion. I 
will try to clear my concern as follows:
In my question I meant whether is it possible to evaluated plastic strain 
component from currently implemented plasticity algorithm as a further 
development of this code?

I would be thankful if you guide or refer me to the possibility from 
implemented plasticity algorithm's point of view. 
Normally the way I know is to use the plastic slip factor (calculated in 
one of the plasticity algorithm's step) to evaluate the plastic strain 
component but to me the currently implemented algorithm seems a bit 
different than normally mentioned in text books.

Then as a step further I would be trying to store this plastic strain in 
cells or Gauss points along with the modified yield strength (due to 
isotropic hardening) so that history of loading is stored too in the 
domain.   
Looking forward to your guiding response. Thank you once again for your 
concern and consistent guidance! 

Best regards,
Muhammad

On Friday, February 21, 2020 at 3:05:33 PM UTC+1, Wolfgang Bangerth wrote:
>
> On 2/21/20 4:25 AM, Muhammad Mashhood wrote: 
> >Thank you for sharing the tutorial 
> step. I 
> > am using the plasticity (material non linearity) part of it with the 
> surface 
> > force (Neuman BC) as a mechanical load. When I remove the load the 
> plasticized 
> > domain comes back to its original (undeformed) state. 
> > *I was wondering if this code with current mathematical model of 
> plasticity 
> > (as mentioned in the corresponding research article) could be further 
> > developed to evaluate the plastic strain of the plasticized region?* 
>
> Are you asking whether it is *possible*, or whether *we* could further 
> develop 
> the code? The first for sure, I don't think that it would be very 
> difficult to 
> add this functionality. The latter probably not -- a lot of the 
> development of 
> the tutorials is driven by people who have an interest in need in a 
> particular 
> topic -- so it would require someone volunteering to do the work. 
>
> > Moreover, this plastic deformation could be then stored on Gauss points 
> so 
> > that one can also visualize that what is the final shape of the 
> plasticized 
> > domain after removing load. 
>
> Yes, that too could be done. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/779ab9c5-4687-4107-948f-378f9697b243%40googlegroups.com.


[deal.II] Re: step-42 now available

2020-02-21 Thread Muhammad Mashhood
Dear Prof. Wolfgang,
  Thank you for sharing the tutorial step. 
I am using the plasticity (material non linearity) part of it with the 
surface force (Neuman BC) as a mechanical load. When I remove the load the 
plasticized domain comes back to its original (undeformed) state.
* I was wondering if this code with current mathematical model of 
plasticity (as mentioned in the corresponding research article) could be 
further developed to evaluate the plastic strain of the plasticized region?*
Moreover, this plastic deformation could be then stored on Gauss points so 
that one can also visualize that what is the final shape of the plasticized 
domain after removing load. 
Thank you!  

On Thursday, November 7, 2013 at 12:09:32 AM UTC+1, Wolfgang Bangerth wrote:
>
>
> All, 
> let me copy a brief item from the news file that may be of interest to 
> you: 
> ... 
>  step-42, written by Joerg Frohne, Timo Heister and Wolfgang 
>  Bangerth, shows how to solve an elasto-plastic contact problem. 
>  The program is an extension of step-41 to a much more complex 
>  equation (nonlinear elasto-plasticity) and also demonstrates 
>  how to compute solutions for such problems in parallel. 
> ... 
> This program is now available at 
>http://www.dealii.org/developer/doxygen/deal.II/step_42.html 
> and will be part of the next deal.II release as well! 
>
> Cheers 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth   email:bang...@math.tamu.edu 
>  
>  www: http://www.math.tamu.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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/f8fa221f-a8d9-4390-9526-e55691956c96%40googlegroups.com.


Re: [deal.II] small strain (additive strain decomposition) elastoplastic code

2019-11-24 Thread Muhammad Mashhood
Great idea Prof. Bangerth. Thanks! 

On Thursday, November 21, 2019 at 7:02:48 PM UTC+1, Wolfgang Bangerth wrote:
>
> On 11/21/19 10:41 AM, Muhammad Mashhood wrote: 
> >  Hi! I am trying to setup quasi static 
> > thermoelastoplastic code using the step-26 (thermal analysis) and 
> step-42 
> > (elastoplastic dynamics). But there is one limitation after coupling 
> both 
> > physics with these two codes that when the thermal or mechanical loading 
> is 
> > removed (after the already certain cells of the domain are plasticized) 
> the 
> > body comes back into the original state of zero displacement or zero 
> strain 
> > every where. In summary it does not stores the plastic strain at the 
> end. 
> > Does anyone have idea if there is already any other deal.ii code for 
> small 
> > strain elastoplasticity (additive decomposed approach) to be coupled 
> with 
> > thermal analysis? 
> > It would be nice addition in my code to fasten up my project. Thank you 
> in 
> > advance! 
>
> I don't know whether any plasticity codes are publicly available, but you 
> might want to use the list of publications based on deal.II to see what 
> you 
> can find and whether the authors are willing to share their codes with 
> you: 
>https://dealii.org/publications.html#list 
> There is a search box for publications that lists at least 20 publications 
> if 
> you enter "plast". 
>
> I suppose you've already found the code gallery? 
>https://dealii.org/code-gallery.html 
> There are also some codes that might be interesting to you. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/805938c4-946f-42f2-95db-1845c9a2c5bf%40googlegroups.com.


[deal.II] small strain (additive strain decomposition) elastoplastic code

2019-11-21 Thread Muhammad Mashhood
Dear deal.ii users,
Hi! I am trying to setup quasi static 
thermoelastoplastic code using the step-26 (thermal analysis) and step-42 
(elastoplastic dynamics). But there is one limitation after coupling both 
physics with these two codes that when the thermal or mechanical loading is 
removed (after the already certain cells of the domain are plasticized) the 
body comes back into the original state of zero displacement or zero strain 
every where. In summary it does not stores the plastic strain at the end.
Does anyone have idea if there is already any other deal.ii code for small 
strain elastoplasticity (additive decomposed approach) to be coupled with 
thermal analysis? 
It would be nice addition in my code to fasten up my project. Thank you in 
advance!

*Regards,*
Muhammad Mashhood  

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/bcb1f817-afbe-4449-bb4e-fd28665c7259%40googlegroups.com.


Re: [deal.II] Re: Thermoelastic Problem

2019-08-08 Thread Muhammad Mashhood
Prof. Wolfgang,
 Thank you for the concern and response. I got your 
point there. I will try it in this way then. :)

On Wednesday, August 7, 2019 at 6:38:53 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 8/5/19 3:40 AM, Muhammad Mashhood wrote: 
> > The only thing is that I was wondering if I might be using extra 
> processing 
> > and memory by defining the fe_temperature, dof_handler_temperature and 
> > fe_values_temperature by defining them again in the solid mechanics 
> program. 
> > And if I am, then would there be any alternative method where I can use 
> the 
> > *const SmartPointer > *and *const 
> SmartPointer > FE_Q > *or something similar**to return *fe_temperature* and 
> > *dof_handler_temperature* from *HeatEquation* class to *SolidMechanics* 
> class 
> > (where they are being used for evaluating q_point temperature as I 
> mentioned 
> > above) ? Thank you! 
>
> Muhammad, 
> you are in essence asking general C++ programming questions about the 
> difference between regular member variables and pointers, and how to 
> return 
> objects by value, by reference, or by pointer. The answer is that yes, you 
> can 
> do as you suggest above. But I would suggest you take a look at a good C++ 
> book or online resource to understand *why* the answer is yes :-) 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/fdccffe8-426e-48d3-a90a-cefcdfbe52b2%40googlegroups.com.


Re: [deal.II] Re: Thermoelastic Problem

2019-08-05 Thread Muhammad Mashhood
Dear Prof. Wolfgang,
  Thank you for your concern and 
understanding. 
Yes you are right. I tried something similar instead of copying the 
triangulation. 
I used *const SmartPointer >* to transfer 
triangulation between both thermal and the solid mechanics classes and 
seemingly the objective of using same triangulation for both parts is full 
filled also with same refinement and coarsening. 
While for the sake of using different *dof_handler* for temperature and 
solid mechanics, I currently have to define again the 
temperature_dof_handler as well as the fe_temperature objects in the solid 
mechanics (class) part to do something like following:

  *dof_handler_temperature.distribute_dofs(fe_temperature);*

*  cell_solid_mech = dof_handler.begin_active();*
*  cell_temperature = dof_handler_temperature.begin_active();*
(for loop for *cell_solid_mech and **cell_temperature* )





*  fe_values_solid_mech.reinit(cell_solid_mech);  
fe_values_temperature.reinit(cell_temperature);  cell_matrix = 
0;  cell_rhs = 0;  
fe_values_temperature.get_function_values(temperature_solution, 
temperature_solution_qpoint);  *
*fe_values_solid_mech[displacement].get_function_symmetric_gradients(displacement_solution,
   
strain_tensor);*  

So in this way, I am successful in using the common triangulation for both 
parts but with different corresponding dof_handlers.
The only thing is that I was wondering if I might be using extra processing 
and memory by defining the fe_temperature, dof_handler_temperature and 
fe_values_temperature by defining them again in the solid mechanics 
program. And if I am, then would there be any alternative method where I 
can use the *const SmartPointer > *and *const 
SmartPointer > *or something similar to return * 
fe_temperature* and *dof_handler_temperature* from *HeatEquation* class to 
*SolidMechanics* class (where they are being used for evaluating q_point 
temperature as I mentioned above) ? Thank you!

On Sunday, August 4, 2019 at 11:54:58 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 8/2/19 4:01 AM, Muhammad Mashhood wrote: 
> > 
> > considering the above scenario as well as the concerns, I would be 
> grateful to 
> > receive any suggestion from your side. Hope I am clear in my 
> description. 
> > Waiting for your kind response. Thank you in advance! 
>
> Instead of copying triangulations, you always have the option of just 
> creating 
> the two objects the same, and then refining them in exactly the same way. 
> Would that solve your problem? 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/91710d89-ac27-4df9-bbb3-1298853d705f%40googlegroups.com.


[deal.II] Re: Thermoelastic Problem

2019-08-02 Thread Muhammad Mashhood
Hi Daniel,
   Thank you for the suggestion and I also think it can be one 
of the way to successfully run both solutions by sharing information on 
correct corresponding q_points. 
I tried the same approach (as I am also using partitioned approach for 
thermomechanical coupling) but so far my (mesh files being read for both 
thermal and solid mechanics parts are same but ) triangulation are 
different. 
So I also want to use the same triangulation with different dof_handler for 
both parts. 

*The scenario of workflow in my case is following:*
The thermal code uses the *Triangulation triangulation_thermal* while 
the solid mechanics code is using *parallel::distributed::Triangulation 
triangulation_solid*. Yes the thermal part is programmed in serial and the 
solid mechanics part in parallel. The solid mechanics code runs and makes 
the grid with it's triangulation, As I want to use the same triangulation 
so I try to copy this triangulation with function 
*triangulation_solid.copy_triangulation(triangulation_thermal) 
*and here the *triangulation_thermal *is the one which I will pass to the 
name space and class of thermal analysis part before running it. Moreover 
during my analysis of solid mechanics part I also refine the mesh (and 
would also want to use the same refined mesh for the thermal analysis too 
by copying it).  

After describing the scenario following are my concerns where I need your 
expert opinion : 
*1)* when I use the *copy_triangulation() *function, I come across the 
error (even here the mesh is not refined so far but still) mentioning : 




*  void dealii::Triangulation::copy_triangulation(const 
dealii::Triangulation&) [with int dim = 2; int spacedim = 
2]The violated condition was: (vertices.size() == 0) && (levels.size() 
== 0) && (faces == nullptr)Additional information: You are trying to 
perform an operation on a triangulation that is only allowed if the 
triangulation is currently empty. However, it currently stores 100 vertices 
and has cells on 1 levels.*

*2)* As far as the documentation of *tria.h* is concerned it also informs 
that the *copy_triangulation()* cannot copy the refined mesh (where in my 
case the mesh might also get refined during analysis based on certain 
criteria and I would like to use same refined triangulation by copying it 
for thermal analysis so that triangulation is same in both problems).

considering the above scenario as well as the concerns, I would be grateful 
to receive any suggestion from your side. Hope I am clear in my description.
Waiting for your kind response. Thank you in advance!

*Best regards,*
Muhammad

On Thursday, March 3, 2016 at 10:49:37 AM UTC+1, Daniel Arndt wrote:
>
> Hello Sudharsan,
>
> what you want to do is to step through all the cells and reinitialize both 
> DoFHandlers simultaneously, i.e. something like
>
> cell_elastic=dh_elastic.begin_active();
> cell_temperature=dh_temperature.begin_active();
> for (;cell_elastic != dh_elastic.end(); ++cell_elastic, ++cell_temperature)
> {
>   fe_values_elastic.reinit(cell_elastic);
>   fe_values_temperature.reinit(cell_temperature);
>   fe_values_temperature.get_function_values(temperature, 
> local_temperature);
> ...
> }
>
> This of course can only work if both DoFHandlers are based on the same 
> Triangulation.
>
> Best regards,
> Daniel
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/1ca1a6d7-81a2-4353-af83-2d8e4d002c30%40googlegroups.com.


Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

2019-07-12 Thread Muhammad Mashhood
Similarly the example output log file is attached where the case is being 
simulated in which the gravity is acting for first two loading cases (which 
converge successfully) and from 3rd step the thermal load is started acting 
upon the plate and from this very loading step the Newton solution with 
residual: 115.471 is being accepted (and does not change for future Newton 
iterations) although the residuals for CG solver iterations and the 
difference of two consecutive solutions ( i.e. incremental displacements) 
is going even below 1e-6.  

On Friday, July 12, 2019 at 10:46:59 AM UTC+2, Muhammad Mashhood wrote:
>
> Dear Prof Wolfgang,
>   Hi! I am successful in running the code and 
> it is without a doubt a nice addition to deal.ii code gallery. It 
> reproduces the expected result for 3d Beam case now.
> Since I did not find any thermomechanical coupled example so far in 
> deal.ii therefore I want to contribute in the development and widening the 
> scope of this code by coupling it with heat equation of step-26. 
> For this purpose , taking your lectures as a reference, Initially for 
> testing purpose (i.e. before importing temperature solution from step-26) , 
> I have added the thermal load in the *cell_rhs* as following:
>
>
>
>
>
>
>
>
>
>
>
>
> *  SymmetricTensor<2, dim> thermal_strain_qpoint;  
> /// assigning thermal strain as +ve temperature 
> change in whole body (i.e. all cells expanding equally) 
>   for 
> (unsigned int i=0; i for (unsigned int j=0; j   if (i==j)  
> thermal_strain_qpoint[i][j] = (1-0.3) * 600e-6;//1e-3 ;  // (1-nu) * 
> alpha * del T  else
>   thermal_strain_qpoint[i][j] = 
> 0*1e-3;  // no shear thermal strain in case of homogenous material 
> properties   
> *
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *  for (unsigned int j = 0; j < dofs_per_cell; 
> ++j)cell_matrix(i, j) += 
> (stress_phi_i  * 
> fe_values[displacement].symmetric_gradient(j, 
> q_point)  * 
> fe_values.JxW(q_point));  cell_rhs(i) += 
> (   ( 
> stress_phi_i * 
> incremental_strain_tensor[q_point] )   
> -   ( ( 
> stress_strain_tensor   * 
> fe_values[displacement].symmetric_gradient(i, 
> q_point)) * tmp_strain_tensor_qpoint ) 
>+   ( 
> fe_values[displacement].value(i, 
> q_point) * rhs_values_body_force )
>+   ( 
> fe_values[displacement].symmetric_gradient(i, q_point)
> * stress_strain_tensor * thermal_strain_qpoint   ) // 
> adding the thermal loading force  produced from thermal 
> strains ) * fe_values.JxW(q_point);*
>
> The solid geometry is in the form of rectangular plate (as shown in the 
> attachment where mesh is even finer in the example being tested) with zero 
> displacement (Dirchlet BC) at left edge and so far no mechanical traction 
> load is applied.
> In the result the displacement result is qualitatively as per the 
> expectation i.e. the plate is expanding from other three ends but the 
> System residuals in Newton iterations are of the order of 1e+4 or even more.
> I do not have much experience in under concentration mathematical approach 
> or I might be mistaking in writing the code for thermal loading force term 
> as per deal.ii standards (because the *rhs_values_body_force *term 
> already present in code is even bigger in numerical quantity than the 
> thermal loading term which is added by me but still it lets system converge 
> for small residuals of 1e-5 during solution) therefore I would be grateful 
> to you for any guiding response in my this course of development. Thank 
> you!  
>
>
> On Monday, June 24, 2019 at 10:20:51 AM UTC+2, Muhammad Mashhood wrote:
>>
>> Thank you Prof Wolfgang for your possible support and concern. I will be 
>> waiting for the further support from 

Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

2019-07-12 Thread Muhammad Mashhood
Dear Prof Wolfgang,
  Hi! I am successful in running the code and 
it is without a doubt a nice addition to deal.ii code gallery. It 
reproduces the expected result for 3d Beam case now.
Since I did not find any thermomechanical coupled example so far in deal.ii 
therefore I want to contribute in the development and widening the scope of 
this code by coupling it with heat equation of step-26. 
For this purpose , taking your lectures as a reference, Initially for 
testing purpose (i.e. before importing temperature solution from step-26) , 
I have added the thermal load in the *cell_rhs* as following:












*  SymmetricTensor<2, dim> thermal_strain_qpoint;  
/// assigning thermal strain as +ve temperature 
change in whole body (i.e. all cells expanding equally) 
  for 
(unsigned int i=0; i
> Thank you Prof Wolfgang for your possible support and concern. I will be 
> waiting for the further support from the author to successfully run it and 
> to understand the workflow correctly. 
>
> On Saturday, June 22, 2019 at 1:51:10 AM UTC+2, Wolfgang Bangerth wrote:
>>
>>
>> Muhammad, 
>> let me bring the original author of the program (Seyed Shahram Ghorashi) 
>> into 
>> the loop as well. 
>>
>> > I ran the case of "Cantiliver_beam_3d" and it returned the results 
>> after 
>> > couple of minutes as mentioned in the attachement (where per time step, 
>> > seemingly only one iteration was performed in Newton method and in all 
>> > increamental load steps the result values are zero for both stress and 
>> > displacement). 
>>
>> Good question. I can confirm that that is what the program generates 
>> (though 
>> at least the dual solution is non-zero), but as with all of the code 
>> gallery 
>> programs, we just make them available for others to look at -- we don't 
>> generally know what specifically they are doing, or whether they are 
>> correct. 
>> You will have to ask Seyed Shahram Ghorashi this question. 
>>
>>
>> > Secondly I tried to run the case "Thick_tube_internal_pressure" which 
>> first 
>> > popped up the dialog message of : 
>>  > [...] 
>> > Where as per my understanding of template based nature of deall.ii and 
>> also 
>> > this case is 2d so if I change the *dim = 2* from originally *dim = 3* 
>> in main 
>> > function of elastoplastic.cc 
>>
>> Yes, this is the correct solution. 
>>
>>
>> > then the following error comes during compilation : 
>> > [...] 
>>
>> Yes, I can confirm this as well. I will admit that I don't think this 
>> ever worked. 
>>
>> In the end, this is really the limitation of the code gallery. We see it 
>> as a 
>> way for our users to share codes that may be of use to others in the 
>> community, but we do not endorse them or verify the quality of these 
>> codes. 
>> It's also quite possible that they *used* to work correctly with older 
>> deal.II 
>> versions, but don't any more -- I could imagine that being the situation 
>> with 
>> the first problem above. 
>>
>> Let's hope that Seyed has something to add that help you! 
>>
>> Best 
>>   WB 
>>
>> -- 
>>  
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/eeefe5f2-0947-4e02-8f12-37d6dbe8f221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


solution-0001-.eps
Description: PostScript document


Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

2019-06-24 Thread Muhammad Mashhood
Thank you Prof Wolfgang for your possible support and concern. I will be 
waiting for the further support from the author to successfully run it and 
to understand the workflow correctly. 

On Saturday, June 22, 2019 at 1:51:10 AM UTC+2, Wolfgang Bangerth wrote:
>
>
> Muhammad, 
> let me bring the original author of the program (Seyed Shahram Ghorashi) 
> into 
> the loop as well. 
>
> > I ran the case of "Cantiliver_beam_3d" and it returned the results after 
> > couple of minutes as mentioned in the attachement (where per time step, 
> > seemingly only one iteration was performed in Newton method and in all 
> > increamental load steps the result values are zero for both stress and 
> > displacement). 
>
> Good question. I can confirm that that is what the program generates 
> (though 
> at least the dual solution is non-zero), but as with all of the code 
> gallery 
> programs, we just make them available for others to look at -- we don't 
> generally know what specifically they are doing, or whether they are 
> correct. 
> You will have to ask Seyed Shahram Ghorashi this question. 
>
>
> > Secondly I tried to run the case "Thick_tube_internal_pressure" which 
> first 
> > popped up the dialog message of : 
>  > [...] 
> > Where as per my understanding of template based nature of deall.ii and 
> also 
> > this case is 2d so if I change the *dim = 2* from originally *dim = 3* 
> in main 
> > function of elastoplastic.cc 
>
> Yes, this is the correct solution. 
>
>
> > then the following error comes during compilation : 
> > [...] 
>
> Yes, I can confirm this as well. I will admit that I don't think this ever 
> worked. 
>
> In the end, this is really the limitation of the code gallery. We see it 
> as a 
> way for our users to share codes that may be of use to others in the 
> community, but we do not endorse them or verify the quality of these 
> codes. 
> It's also quite possible that they *used* to work correctly with older 
> deal.II 
> versions, but don't any more -- I could imagine that being the situation 
> with 
> the first problem above. 
>
> Let's hope that Seyed has something to add that help you! 
>
> Best 
>   WB 
>
> -- 
>  
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/9cac3aa3-fa19-4dcd-acbe-29b251186028%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

2019-06-18 Thread Muhammad Mashhood
Thank you Prof. Wolfgang for the response! I will try my best to elaborate 
it more.
I ran the case of "Cantiliver_beam_3d" and it returned the results after 
couple of minutes as mentioned in the attachement (where per time step, 
seemingly only one iteration was performed in Newton method and in all 
increamental load steps the result values are zero for both stress and 
displacement).

Secondly I tried to run the case "Thick_tube_internal_pressure" which first 
popped up the dialog message of : 
























*TimerOutput objects finalize timed values printed to thescreen by 
communicating over MPI in their destructors.Since an exception is currently 
uncaught, thissynchronization (and subsequent output) will be skipped 
toavoid a possible 
deadlock.-ERROR: 
Uncaught exception in MPI_InitFinalize on proc 0. Skipping MPI_Finalize() 
to avoid a 
deadlock.Exception on 
processing: An 
error occurred in line <3617> of file 

 
in functionvoid ElastoPlastic::ElastoPlasticProblem::make_grid() 
[with int dim = 3]The violated condition was: dim == 2Additional 
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).Aborting!*
Where as per my understanding of template based nature of deall.ii and also 
this case is 2d so if I change the *dim = 2* from originally *dim = 3* in 
main function of elastoplastic.cc then the following error comes during 
compilation : 















*/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:
 
In instantiation of ‘void 
ElastoPlastic::ElastoPlasticProblem::make_grid() [with int dim = 
2]’:/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:7100:14:
   
required from ‘void ElastoPlastic::ElastoPlasticProblem::run() [with 
int dim = 
2]’/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:7265:21:
   
required from 
here/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:3796:30:
 
error: invalid initialization of reference of type 
‘dealii::Triangulation<3, 3>&’ from expression of type 
‘dealii::parallel::distributed::Triangulation<2, 2>’ 
extrude_triangulation(triangulation_2d,  
^/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:107:3:
 
note: in passing argument 4 of ‘void 
ElastoPlastic::extrude_triangulation(const dealii::Triangulation<2, 2>&, 
unsigned int, double, dealii::Triangulation<3, 3>&)’   
extrude_triangulation(const Triangulation<2, 2> ,   
^/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:3959:30:
 
error: invalid initialization of reference of type 
‘dealii::Triangulation<3, 3>&’ from expression of type 
‘dealii::parallel::distributed::Triangulation<2, 2>’ 
extrude_triangulation(triangulation_2d,  
^/home/muhammad/installed_software/dealii-9.1.1/examples/Goal-oriented_mesh_adaptivity_in_elastoplasticity_problems/elastoplastic.cc:107:3:
 
note: in passing argument 4 of ‘void 
ElastoPlastic::extrude_triangulation(const dealii::Triangulation<2, 2>&, 
unsigned int, double, dealii::Triangulation<3, 3>&)’   
extrude_triangulation(const Triangulation<2, 2> ,*
Currently I am not changing anything in ".prm" and ".cc" and running it as 
it is downloading from the code gallery. May be I am missing some 
instructions to run it so any help or hint in this regard would be much 
appreciated. Thank you very much in advance!


On Monday, June 17, 2019 at 6:36:23 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 6/17/19 1:50 AM, Muhammad Mashhood wrote: 
> >  I recently started working with deal.ii and 
> want 
> > to work with material models from material mechanics. For this so far I 
> came 
> > across nicely

[deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "

2019-06-17 Thread Muhammad Mashhood
Dear deal.ii users,
I recently started working with deal.ii and 
want to work with material models from material mechanics. For this so far 
I came across nicely written and well worked code of "The 'Goal-oriented 
mesh adaptivity in elastoplasticity problems " in the code gallery. I tried 
to compile and run it on deal.ii 9.1.1 and one of the case ran but not 
giving displacement and stresses values in the loading step output results. 
Anyone worked with it is warmly welcome to suggest or share any possible 
problem which I might not be taking care of? Thank you in advance!

Regards,
Muhammad

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/0212a592-4d00-4eab-aa24-84818ba9bda0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Thermal Expansion

2019-05-29 Thread Muhammad Mashhood
Hi Andrew! I am also working on the same problem and would be interested to 
have a look into Thesis but the link says it has been removed.

On Tuesday, October 7, 2014 at 12:27:09 PM UTC+2, mac wrote:
>
> The link below is to an MSc thesis that details all the steps to solve the 
> thermoelastic problem in deal.II
> https://copy.com/lGuC3Md4aiIRk9t8
>
> Andrew
>
> On 7 Oct 2014, at 12:18, Ehsan > wrote:
>
> Hi,
>
> I want to model a plate under mechanical and thermal loadings.
> The plate is in steady state condition and the material is considered to 
> be homogeneous isotropic elastic material.
>
> The Thermal BCs are:
> Left edge: prescribed temperature change.
> Right edge: constant temperature (zero temperature change)
> Top and bottom edges: adiabatic.
>
> I modelled this problem with only mechanical loading and now I want to add 
> thermal part. I want to solve the problem in monolithic way.
>
> My question is:
> Which steps I should I study?
>
> Best regards.
> Ehsan
>
> -- 
> 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 dea...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/6da372dd-5e32-4452-8e2f-d30c0bd0dac3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Temperature osscilations for low thermal diffusivity materials

2019-05-28 Thread Muhammad Mashhood
Thanks for sharing the observations Chinedu. So far I am keeping the source 
term off for a while i.e. not needed currently. I am sharing the result and 
description in the attachment. 

On Tuesday, May 28, 2019 at 8:15:14 AM UTC+2, Chinedu Nwaigwe wrote:
>
> Wolfang is right.  Negligible values of diffusion or thermal coefficients 
> lead to a compete change in the physics of the problem.  In that case if 
> there are source terms the solution might become negative and if there is 
> no source it will become steady. Things might get worse if advection term 
> is involved. 
>
>
>
>
>
>
>
> On Mon, May 27, 2019, 21:59 Wolfgang Bangerth   wrote:
>
>> On 5/27/19 11:01 AM, Muhammad Mashhood wrote:
>> >  I am working with deal.ii step-26 to implement 
>> temperature 
>> > dependent thermal diffusivity. Currently for thermal diffusivity values 
>> > 
>> > order of 1e-2 the results are quit satisfactory but if I use the low 
>> thermal 
>> > diffusivity values like the order of 1e-6 to 1e-3, I get temperature 
>> > oscillations (temperature going to -ve value even with all positive 
>> > temperature initial and boundary conditions in domain and at 
>> boundaries).
>> > If anyone has faced the same issue in thermal conduction simulations or 
>> knows 
>> > the criteria to keep simulation stable in terms of thermal diffusivity, 
>> time 
>> > step and mesh size then kindly suggest and share the opinion. Thank you 
>> in 
>> > advance!
>>
>> In the limit of no thermal diffusivity, your equation ends up as an 
>> ordinary 
>> differential equation and that means that you lose stability in the H^1 
>> norm 
>> -- in other words, you will get oscillations. That's just part of the 
>> nature 
>> of the equation.
>>
>> What is the situation you are trying to model that leads to such a small 
>> diffusivity?
>>
>> 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 dea...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/dealii/84cc645b-9b75-79ec-8c3b-53d428ab8fc8%40colostate.edu
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/7b7f7a96-aa34-47ae-8abf-197708ebc41b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


detail
Description: Binary data


Re: [deal.II] Temperature osscilations for low thermal diffusivity materials

2019-05-28 Thread Muhammad Mashhood
Hi Prof. Wolfgang! Thank you for the response. Indeed the solution is quite 
reasonable and validated with analytical solution if diffusivity is kept 
bigger. 
Actually in my case I am using the metals and metallic alloys where the 
thermal diffusivity are of the range of 1e-5 to 1e-4 m^2/s (I wonder there 
might be an alternative way to simulate with these physical properties 
values). 
Just as a further explanation, the approach to vary the diffusivity is also 
in a way that it is calculated from U_old temperature vector and remains 
same for current time step. 

On Monday, May 27, 2019 at 10:58:59 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 5/27/19 11:01 AM, Muhammad Mashhood wrote: 
> >  I am working with deal.ii step-26 to implement 
> temperature 
> > dependent thermal diffusivity. Currently for thermal diffusivity values 
> > 
> > order of 1e-2 the results are quit satisfactory but if I use the low 
> thermal 
> > diffusivity values like the order of 1e-6 to 1e-3, I get temperature 
> > oscillations (temperature going to -ve value even with all positive 
> > temperature initial and boundary conditions in domain and at 
> boundaries). 
> > If anyone has faced the same issue in thermal conduction simulations or 
> knows 
> > the criteria to keep simulation stable in terms of thermal diffusivity, 
> time 
> > step and mesh size then kindly suggest and share the opinion. Thank you 
> in 
> > advance! 
>
> In the limit of no thermal diffusivity, your equation ends up as an 
> ordinary 
> differential equation and that means that you lose stability in the H^1 
> norm 
> -- in other words, you will get oscillations. That's just part of the 
> nature 
> of the equation. 
>
> What is the situation you are trying to model that leads to such a small 
> diffusivity? 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/d85f0475-87d1-420e-930f-ad27e6eff6a7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Temperature osscilations for low thermal diffusivity materials

2019-05-27 Thread Muhammad Mashhood
Dear users,
I am working with deal.ii step-26 to implement temperature 
dependent thermal diffusivity. Currently for thermal diffusivity values > 
order of 1e-2 the results are quit satisfactory but if I use the low 
thermal diffusivity values like the order of 1e-6 to 1e-3, I get 
temperature oscillations (temperature going to -ve value even with all 
positive temperature initial and boundary conditions in domain and at 
boundaries).
If anyone has faced the same issue in thermal conduction simulations or 
knows the criteria to keep simulation stable in terms of thermal 
diffusivity, time step and mesh size then kindly suggest and share the 
opinion. Thank you in advance! 

Regards,
Mashhood

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/ea91ded9-47ef-4db9-bc2b-d62b63779df9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[deal.II] Re: Thermoelastic Problem

2019-05-24 Thread Muhammad Mashhood
Hi Joerg and Lisa!
Thank you for informative reply and posting this concern on the forum. I am 
also interested in thermoelastic problem and new use of deal.ii. 
My question is that other than the tutorial steps 26 & 18 or 20,21 & 22, is 
there pre-developed application at "https://www.dealii.org/; for this field 
of study? Thank you!   

On Wednesday, August 27, 2014 at 12:06:40 PM UTC+2, deal.II-MailingList 
wrote:
>
> Hello Lisa,
>
> I suppose that it depends on how you want to solve your thermoelastic 
> problem.
> Do you want to assemble one big system which contains one block for the 
> elastic equation,
> another block for the heat equation and coupling blocks? Then you could 
> solve that system
> in a monolithic way. Therefore you should have a look at step 20, 21 and 
> 22.
> If you want to solve the elastic equation and the heat equation 
> alternately a look to step 18
> and 26 might be enough.
> step 18 shows an example for how to solve an elastic equation as a time 
> depend problem.
> And step 26 gives an example for how to deal with the heat equation.
>
> Since I am currently working on a thermoelastic problem let me know if you 
> have further
> questions.
>
> Best,
> Joerg
>
> Am Dienstag, 26. August 2014 15:21:25 UTC+2 schrieb Lisa Collins:
>>
>> Hi,
>>
>> I want to start deal.ii and model a thermoelastic problem in 2D & 3D.
>>
>> Can you please guide me which steps I should study.
>> Which step should be considered as the base of my work and by modifying 
>> it I can model a thermoelastic problem?
>>
>> Best  regards
>> Lisa
>>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/2a596416-2d5e-4aed-a80b-efc5c0bb66b7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

2019-04-29 Thread Muhammad Mashhood
Thank you professor for your concern. No I am currently not using the debug 
mode rather running it normally using the build targets technique you 
mentioned in tutorials for eclipse. Although it is not producing the error 
but which ever matrix I give to this function to write boundary rhs terms, 
it does not modify it or give the output in that vector. e.g. If i give 
"tmp" as zeros or non zeros entry vector as argument it still remains the 
same before and after running the function.  

On Saturday, April 27, 2019 at 5:26:03 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/26/19 3:42 AM, Muhammad Mashhood wrote: 
> > Thank you Prof. Bangerth for the correction that was quit helping. 
> Currently 
> > the code started running but unfortunately the function is returning 
> with the 
> > zero "tmp" vector. Any possible correction? 
>
> Hm, I wonder if it is even implemented in the 1d case. Looking into the 
> deal.II source files, I can't see how your program actually runs without 
> producing an error. Are you using debug mode? 
>
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-26 Thread Muhammad Mashhood
It seems that "tmp" vector stays unchanged i.e. function is seemingly not 
assigning any face rhs values to "tmp" vector. 

On Friday, April 26, 2019 at 11:42:09 AM UTC+2, Muhammad Mashhood wrote:
>
> Thank you Prof. Bangerth for the correction that was quit helping. 
> Currently the code started running but unfortunately the function is 
> returning with the zero "tmp" vector. Any possible correction? 
>
>
>
>
>
>
> *tmp.reinit (solution.size());
> VectorTools::create_boundary_right_hand_side(dof_handler,  
>  QGauss(fe.degree+1),
> 
>  ConstantFunction(1), 
>  tmp);*
>
> Currently I also did not specify the id of the node where I want to 
> impose  "*ConstantFunction(1)*" value 1 supposing that the "
> *create_boundary_right_hand_side*" will apply it itself on both ends when 
> ids not specified explicitly. 
>
> On Thursday, April 25, 2019 at 8:49:04 PM UTC+2, Wolfgang Bangerth wrote:
>>
>> On 4/25/19 9:46 AM, Muhammad Mashhood wrote: 
>> > 
>> > As unlike the step-8 here in step-26 the rhs is being formed directly 
>> > globally as "system_rhs" using "create_right_hand_side()" function so 
>> > can I use the "create_boundary_right_hand_side()" function using 
>> > following lines of code? 
>>
>> It is definitely possible to *add* to the vector you get from 
>> create_boundary_rhs(). But in this call... 
>>
>> > / 
>> > / 
>> > /std::map::iterator 
>> > it=boundary_count.begin(); 
>> > 
>> >  VectorTools::create_boundary_right_hand_side(dof_handler, 
>> >   
>> >   QGauss(fe.degree+1), 
>> >   rhs_function, 
>> >   tmp,/ 
>> > / it->first);/ 
>> > where the "rhs_function" provides the values of /g0/ and /g1 /at 
>> > boundary node points and "it->first" is the boundary id where I want to 
>> > apply the BC. 
>>
>> ...you are asked to pass in a Quadrature, not a Quadrature. 
>> Consequently, the code does not compile. This is actually stated quite 
>> explicitly in the second part of the error message: 
>>
>> dealii::VectorTools::create_boundary_right_hand_side(const 
>> dealii::DoFHandler&, const dealii::Quadrature<(dim - 
>> 1)>&, const dealii::Function> VectorType::value_type>&, VectorType&, const std::set&) 
>> [with int dim = 1; int spacedim = 1; VectorType = 
>> dealii::Vector; typename VectorType::value_type = double] 
>> void create_boundary_right_hand_side 
>>  ^ 
>> /usr/local/include/deal.II/numerics/vector_tools.h:2105:8: note:   no 
>> known conversion for argument 2 from ‘dealii::QGauss<1>’ to ‘const 
>> dealii::Quadrature<0>&’ 
>>
>>
>> Best 
>>   WB 
>>
>> -- 
>>  
>> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-26 Thread Muhammad Mashhood
Thank you Prof. Bangerth for the correction that was quit helping. 
Currently the code started running but unfortunately the function is 
returning with the zero "tmp" vector. Any possible correction? 






*tmp.reinit (solution.size());
VectorTools::create_boundary_right_hand_side(dof_handler,  
 QGauss(fe.degree+1),

 ConstantFunction(1), 
 tmp);*

Currently I also did not specify the id of the node where I want to impose  
"*ConstantFunction(1)*" value 1 supposing that the "
*create_boundary_right_hand_side*" will apply it itself on both ends when 
ids not specified explicitly. 

On Thursday, April 25, 2019 at 8:49:04 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/25/19 9:46 AM, Muhammad Mashhood wrote: 
> > 
> > As unlike the step-8 here in step-26 the rhs is being formed directly 
> > globally as "system_rhs" using "create_right_hand_side()" function so 
> > can I use the "create_boundary_right_hand_side()" function using 
> > following lines of code? 
>
> It is definitely possible to *add* to the vector you get from 
> create_boundary_rhs(). But in this call... 
>
> > / 
> > / 
> > /std::map::iterator 
> > it=boundary_count.begin(); 
> > 
> >  VectorTools::create_boundary_right_hand_side(dof_handler, 
> >   
> >   QGauss(fe.degree+1), 
> >   rhs_function, 
> >   tmp,/ 
> > / it->first);/ 
> > where the "rhs_function" provides the values of /g0/ and /g1 /at 
> > boundary node points and "it->first" is the boundary id where I want to 
> > apply the BC. 
>
> ...you are asked to pass in a Quadrature, not a Quadrature. 
> Consequently, the code does not compile. This is actually stated quite 
> explicitly in the second part of the error message: 
>
> dealii::VectorTools::create_boundary_right_hand_side(const 
> dealii::DoFHandler&, const dealii::Quadrature<(dim - 
> 1)>&, const dealii::Function VectorType::value_type>&, VectorType&, const std::set&) 
> [with int dim = 1; int spacedim = 1; VectorType = 
> dealii::Vector; typename VectorType::value_type = double] 
> void create_boundary_right_hand_side 
>  ^ 
> /usr/local/include/deal.II/numerics/vector_tools.h:2105:8: note:   no 
> known conversion for argument 2 from ‘dealii::QGauss<1>’ to ‘const 
> dealii::Quadrature<0>&’ 
>
>
> Best 
>   WB 
>
> -- 
>  
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-25 Thread Muhammad Mashhood
6.cc.o] Error 
1CMakeFiles/step-26.dir/build.make:62: recipe for target 
'CMakeFiles/step-26.dir/step-26.cc.o' failedmake[2]: *** 
[CMakeFiles/step-26.dir/all] Error 2make[3]: Leaving directory 
'/home/muhammad/software/dealii-8.5.0/examples/step-26'CMakeFiles/Makefile2:195:
 
recipe for target 'CMakeFiles/step-26.dir/all' failedmake[2]: Leaving 
directory 
'/home/muhammad/software/dealii-8.5.0/examples/step-26'CMakeFiles/Makefile2:271:
 
recipe for target 'CMakeFiles/run.dir/rule' failedmake[1]: Leaving 
directory 
'/home/muhammad/software/dealii-8.5.0/examples/step-26'Makefile:196: recipe 
for target 'run' failedmake[1]: *** [CMakeFiles/run.dir/rule] Error 2make: 
*** [run] Error 2"/usr/bin/make -j24 run" terminated with exit code 2. 
Build might be incomplete.*




On Wednesday, April 10, 2019 at 4:16:02 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/10/19 4:52 AM, Muhammad Mashhood wrote: 
> > 
> > _But the step-26 which I am now concerned about is directly forming rhs 
> > somehow using the function:_ 
> > 
> >  RightHandSide rhs_function; 
> >  rhs_function.set_time(time); 
> >  VectorTools::create_right_hand_side(dof_handler, 
> >  QGauss(fe.degree+1), 
> >  rhs_function, 
> >  tmp); 
> > So how can I possibly implement heat flux on cell faces in this example 
> case 
> > step-26 ? If I can, then I guess my problem is solved to learn 
> implementing 
> > Neuman BC for Heat equation in deal.ii. Thank you very much in advance? 
>
> You just need to replace the call to this one function by something like 
> the 
> code snippet you had shown above. 
>
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-17 Thread Muhammad Mashhood
Thank you I will try this way and what about changing the Thermal Diffusion 
"k" value in this step-26 case. As currently it is 1 but if I want to 
change it shall I multiply value of "k" thermal diffusivity with Laplace 
Matrix "A" or is there another already developed way in deal.ii ? Thank you 
in advance! 

On Wednesday, April 10, 2019 at 4:16:02 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/10/19 4:52 AM, Muhammad Mashhood wrote: 
> > 
> > _But the step-26 which I am now concerned about is directly forming rhs 
> > somehow using the function:_ 
> > 
> >  RightHandSide rhs_function; 
> >  rhs_function.set_time(time); 
> >  VectorTools::create_right_hand_side(dof_handler, 
> >  QGauss(fe.degree+1), 
> >  rhs_function, 
> >  tmp); 
> > So how can I possibly implement heat flux on cell faces in this example 
> case 
> > step-26 ? If I can, then I guess my problem is solved to learn 
> implementing 
> > Neuman BC for Heat equation in deal.ii. Thank you very much in advance? 
>
> You just need to replace the call to this one function by something like 
> the 
> code snippet you had shown above. 
>
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-10 Thread Muhammad Mashhood
Dear Prof. Bangerth,
 Thank you for the guidance and correction. 
I got the point now that for Neuman conditions I shall iterate for face 
cells along desired edge for imposing condition like in the previous case 
of step-8. I also went through the step-7, thank you for the guidance it 
made me understand more about the face_cell_values for making rhs. As far 
as I have understood the step-7 is iterating through each cell and 
implementing simply the Neuman condition at the face cells:

for (; cell!=endc; ++cell)
{
cell_matrix = 0;
cell_rhs = 0;
fe_values.reinit 
<https://www.dealii.org/current/doxygen/deal.II/classFEValues.html#aec8f5b8b3e4c5dcf35dfd029a1ecbbd0>
 
(cell);
right_hand_side.value_list (fe_values.get_quadrature_points 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#a5f8732ebe2d3c6746f6de26a79cb1e45>
(),
rhs_values);
for (unsigned int q_point=0; q_pointhttps://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ac4cee7628c2903a89c5c399fddeb00a5>(i,q_point)
 
*
fe_values.shape_grad 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ac4cee7628c2903a89c5c399fddeb00a5>
(j,q_point)
+
fe_values.shape_value 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#abe4de48ff59778bb82a0ec13037804aa>(i,q_point)
 
*
fe_values.shape_value 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#abe4de48ff59778bb82a0ec13037804aa>(j,q_point))
 
*
fe_values.JxW 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ad097580a2f71878695096cc73b271b9d>
(q_point));
cell_rhs(i) += (fe_values.shape_value 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#abe4de48ff59778bb82a0ec13037804aa>(i,q_point)
 
*
rhs_values [q_point] *
fe_values.JxW 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ad097580a2f71878695096cc73b271b9d>
(q_point));
}
for (unsigned int face_number=0; 
face_number::faces_per_cell; ++face_number)
if (cell->face(face_number)->at_boundary()
&&
(cell->face(face_number)->boundary_id() == 1))
{
fe_face_values.reinit 
<https://www.dealii.org/current/doxygen/deal.II/classFEFaceValues.html#af6e079ca7429d54433343d50bd334c3c>
 
(cell, face_number);
for (unsigned int q_point=0; q_pointhttps://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ab1aa3aa2940125b47df95ff82ad733b9>(q_point))
 
*
fe_face_values.normal_vector 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#a130eea0fa89263d93b20521addc830c7>
(q_point));
for (unsigned int i=0; ihttps://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#abe4de48ff59778bb82a0ec13037804aa>(i,q_point)
 
*
fe_face_values.JxW 
<https://www.dealii.org/current/doxygen/deal.II/classFEValuesBase.html#ad097580a2f71878695096cc73b271b9d>
(q_point));
}
}
cell->get_dof_indices (local_dof_indices);
for (unsigned int i=0; i rhs_function;
rhs_function.set_time(time);
VectorTools::create_right_hand_side(dof_handler,
QGauss(fe.degree+1),
rhs_function,
tmp);
So how can I possibly implement heat flux on cell faces in this example 
case step-26 ? If I can, then I guess my problem is solved to learn 
implementing Neuman BC for Heat equation in deal.ii. Thank you very much in 
advance? 



On Wednesday, April 10, 2019 at 5:56:46 AM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/9/19 10:01 AM, Muhammad Mashhood wrote: 
> > I want to apply the heat flux BC on one of the edge instead i.e. *dU(t, 
> x, 
> > y=1)/dy* at top. For this so far I could only find a method to make a 
> heat 
> > source using the already present function as follows: 
>
> I don't know how you use the class you implement, but I would try to avoid 
> all 
> confusion by naming the class RightHandSide: This is the name we generally 
> use 
> for forcing terms of the differential equation, and not for the right hand 
> side of boundary conditions. 
>
> Just like for your previous question, it is not correct to "convert" the 
> right 
> hand side of a boundary condition into a right hand side of the equation. 
> This 
> is mathematically not correct and will not lead to the correct solution. 
>
> Have you looked at step-7? This program deals with Neumann boundary 
> conditions 
> and may have exactly what you are looking for. 
>
> 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/

Re: [deal.II] Imposing the Neumann BC using right_hand_side() function

2019-04-09 Thread Muhammad Mashhood
Sorry if it is not clear. Sure I will explain it a bit more.
In step-26 of tutorials, the (temperature application) Dirchlet BC is 
already implemented. I want to apply the heat flux BC on one of the edge 
instead i.e. *dU(t, x, y=1)/dy* at top. For this so far I could only find a 
method to make a heat source using the already present function as follows:

  template
  class RightHandSide : public Function
  {
  public:
RightHandSide ()
  :
  Function(),
  period (0.2)
{}

virtual double value (const Point ,
  const unsigned int component = 0) const;

  private:
const double period;
  };



  template
  double RightHandSide::value (const Point ,
const unsigned int component) const
  {
(void) component;
Assert (component == 0, ExcIndexRange(component, 0, 1));
Assert (dim == 2, ExcNotImplemented());

const double time = this->get_time();
const double point_within_period = (time/period - 
std::floor(time/period));

if ((point_within_period >= 0.0) && (point_within_period <= 0.2))
  {
if ((p[0] > 0.5) && (p[1] > -0.5))
  return 2;
else
  return 0;
  }
else if ((point_within_period >= 0.5) && (point_within_period <= 0.7))
  {
if ((p[0] > -0.5) && (p[1] > 0.5))
  return 2;
else
  return 0;
  }
else
  return 0;
///
// Applying the Neumann BC in the form of flux producing source or sink 
at top boundary
///

if ((point_within_period >= 0.0) && (point_within_period <= 0.2))
  {

if (p[1] > 0.99)
  return 100;
else
  return 0;

  }

  }

So the question is that is it valid Idea or there can be other idea to 
apply heat flux on the boundary edge in deal.ii step-26 code? Thank you!

On Tuesday, April 9, 2019 at 5:23:04 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/9/19 3:44 AM, Muhammad Mashhood wrote: 
> > Thank you very much Prof. Bangerth. The Neuman condition is now 
> implemented 
> > successfully on the face elements in relatively simpler way (which you 
> > proposed for me). Now I have moved ahead to implement the flux BC on the 
> top 
> > edge of square plate and I am taking help of your tutorial step-26. But 
> in 
> > this code the structure is a bit different than the step-8 i.e. the 
> *cell_rhs 
> > *looks like being formed now in *create_right_hand_side* function. 
> > So my question is that can I simply use the heat source code of 
> following 
> > function: 
> > *template 
> >double RightHandSide::value (const Point , 
> >  const unsigned int component) 
> const* 
> > 
> > to select the points of top edge of the domain to declare the flux input 
> or 
> > Neuman BC (i.e. in other words moving source on top and source now 
> putting 
> > heat inside the domain) or there is other valid way for that? Thank you 
> in 
> > advance for your suggestion! 
>
> I don't think I fully understand what you want to do. Can you state in 
> formulas what you want to implement? How does your boundary conditions 
> look like? 
>
> Best 
>   WB 
>
> -- 
>  
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-09 Thread Muhammad Mashhood
Thank you very much Prof. Bangerth. The Neuman condition is now implemented 
successfully on the face elements in relatively simpler way (which you 
proposed for me). Now I have moved ahead to implement the flux BC on the 
top edge of square plate and I am taking help of your tutorial step-26. But 
in this code the structure is a bit different than the step-8 i.e. the 
*cell_rhs 
*looks like being formed now in *create_right_hand_side* function. 
So my question is that can I simply use the heat source code of following 
function:


*template  double RightHandSide::value (const Point 
,const unsigned int component) const*

to select the points of top edge of the domain to declare the flux input or 
Neuman BC (i.e. in other words moving source on top and source now putting 
heat inside the domain) or there is other valid way for that? Thank you in 
advance for your suggestion!  


On Thursday, April 4, 2019 at 3:10:35 PM UTC+2, Wolfgang Bangerth wrote:
>
> On 4/4/19 4:05 AM, Muhammad Mashhood wrote: 
> > 
> >   for (unsigned int f=0; f :: faces_per_cell; ++f) 
> >  if (cell->face(f)->at_boundary() ) 
> >  { 
> >  fe_face_values.reinit (cell,f); 
> >  for (unsigned int i=0; i >{ 
> >  const unsigned int 
> >  component_i = 
> fe.system_to_component_index(i).first; 
> > 
> >  for (unsigned int q_point=0; 
> q_point > ++q_point) 
> >cell_rhs(i) += 
> fe_face_values.shape_value(i,q_point) * 
> >   rhs_values[q_point][component_i] * 
> >   fe_face_values.JxW(q_point); 
> >  } 
> >  } 
> > 
> > 
> >   Where the *"rhs_values"* are being extracted from my previously 
> mentioned 
> > function "*right_hand_side (fe_values.get_quadrature_points(), 
> rhs_values, 
> > cell);"* in a same loop of "*for (; cell!=endc; ++cell)" *and the code 
> for 
> > this "*right_hand_side" *function is that which I mentioned previously. 
> > In my limited knowledge I am going through each face in cell as in 2D 
> there 
> > are four edges are present and I want to choose the edge number 3 (which 
> is 
> > upper outer edge in my example case). 
>
> The way you do things here does not work. You are assembling boundary 
> terms on 
> an individual face here. You need to evaluate the rhs_values *for this 
> particular face*. In other words, you need to call the function you showed 
> us with 
>fe_face_values.get_quadrature_points() 
> (not fe_values.get_quadrature_points()), and not with an iterator to the 
> cell 
> but with an iterator to the face. 
>
> This way, you do not need the function you showed us guess whether a 
> quadrature point is near a particular boundary -- the function already 
> *knows* 
> that the quadrature points lie on that boundary, because it is only called 
> for 
> such points. 
>
> 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] Imposing the Neumann BC using right_hand_side() function

2019-04-04 Thread Muhammad Mashhood
Thank you Prof. Bangerth for your quick concern. I am on basic level for 
FEM code programming especially deal.ii and also quite only a bit familiar 
with object oriented programming in C++. 
Sorry if my question was not clear, let me explain it a bit:
Actually, I am trying to follow the tutorial step-8 for extending it to 
applying BC upon the labelled edges during meshing in mesh generator. I am 
quit successful in applying Dirchlet (displacement) BC simply using 
function "interpolate_boundary_values()". Now it is time to apply Neumann 
(force) BC. 
For this yes you guessed right that I am using "FEFaceValues" in following 
code as per tutorials:

 for (unsigned int f=0; f :: faces_per_cell; ++f)  
if (cell->face(f)->at_boundary() )
{
fe_face_values.reinit (cell,f);
for (unsigned int i=0; i
> On 4/3/19 8:04 AM, Muhammad Mashhood wrote: 
> > 
> > I am trying to apply the Neumann 
> (force) 
> > BC on the edge using the right_hand_side() function which I modified as 
> following: 
> > 
> > 
> > void right_hand_side (const std::vector > ,   // the 
> active 
> > cell is also imported when right hand side is called to induce some 
> Neumann BC 
> >  std::vector >   , 
> >  typename DoFHandler::active_cell_iterator 
> & 
> > cell_in_rhs) 
> > 
> > for (unsigned int f=0; f < GeometryInfo :: faces_per_cell; ++f) 
> >  { 
> >  if (cell_in_rhs->face(f)->at_boundary() && 
> > cell_in_rhs->face(f)->boundary_id() == 3) 
> >  { 
> >  std::cout << "points.size(): "<< 
> points.size()<<" 
> > :"< >  values[0][1] = 2.0; 
> >  values[2][1] = 2.0; 
> > 
> >  } 
> >   } 
> > 
>
> I don't think I understand this code. The Neumann boundary conditions only 
> appear in *boundary* integrals. How are you using the function you have 
> here? 
> For integrals over cells (using FEValues) or integrals over faces 
> (FEFaceValues)? If it is the latter, you are integrating over *one 
> specific 
> face* of the current cell, so it makes no sense to loop over all faces 
> *within 
> this function*. 
>
> Best 
>   W. 
>
> -- 
>  
> Wolfgang Bangerth  email: bang...@colostate.edu 
>  
> www: http://www.math.colostate.edu/~bangerth/ 
>
>

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


[deal.II] Imposing the Neumann BC using right_hand_side() function

2019-04-03 Thread Muhammad Mashhood
Dear group members, 
   I am trying to apply the Neumann (force) 
BC on the edge using the right_hand_side() function which I modified as 
following:


void right_hand_side (const std::vector > ,   // the 
active cell is also imported when right hand side is called to induce some 
Neumann BC
std::vector >   ,
typename DoFHandler::active_cell_iterator & 
cell_in_rhs)

for (unsigned int f=0; f < GeometryInfo :: faces_per_cell; ++f)
{
if (cell_in_rhs->face(f)->at_boundary() && 
cell_in_rhs->face(f)->boundary_id() == 3)
{
std::cout << "points.size(): "<< 
points.size()<<" :"

Re: [deal.II] Interfacing deal.ii for solution, pre and post-processing

2019-03-15 Thread Muhammad Mashhood
Thank you Jean! That was a very comprehensive summary for me to take 
initial steps and motivation for deal.ii. The main concern from me however 
remains now for the reading and dealing with boundary conditions I am 
interested in my solid mechanics case simulations. If there are some 
external, high end or specialized interfaces present for them too to 
control what has to happen inside of the the BC interpolation functions 
with named boundary ids that would make a lot more ease.   

On Friday, March 15, 2019 at 4:40:43 PM UTC+1, Jean-Paul Pelteret wrote:
>
> Dear Muhammad,
>
> You can look at the documentation to the GridIn 
> <https://dealii.org/current/doxygen/deal.II/classGridIn.html> namespace 
> for some ideas as to which software supports the generation of mesh files 
> that deal.II can read, and the and GridOut 
> <https://dealii.org/current/doxygen/deal.II/classGridOut.html> namespace 
> for the types of output deal.II can make and some programs that can read 
> them in. 
>
> I think that it depends greatly on what you’re trying to accomplish as to 
> what software you may consider using. For example, I often simulate 
> problems that require intricate geometry and, therefore, an intricate mesh. 
> So I use a commercial tool like Cubit to create the mesh and post-process 
> results using Paraview. I would say that GMSH and Salome are two other 
> preprocessors that would be commonly used (but neither of which I have much 
> familiarity with). Of course, deal.II has itself got some basic mesh 
> generation capabilities that may be perfectly suitable for you. Another 
> often-used post-processor is Visit. 
>
> The application of boundary conditions is done differently to how one much 
> setup BCs in a mesh that is then read into, say, ABAQUS. With deal.II you 
> may only specify an identifying number (known as a boundary_id) to the 
> boundaries, which you then interpolate some boundary condition function 
> onto. I know thats some commercial software interprets physical boundary 
> conditions directly from the mesh itself but, since deal.II is a finite 
> element library and not a multi physics library, it would have no 
> understanding of what these types of boundary conditions mean.
>
> Does that help you?
>
> Best,
> Jean-Paul
>
> On 15 Mar 2019, at 16:18, Muhammad Mashhood  > wrote:
>
> Dear all,
> I am new to deal.ii and looking for a nice interfacing tool 
> for making mesh import, BC application, solution and post-processing for 
> simulation cases etc. easy for me. Can anyone give me suggestion regarding 
> this? 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+un...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
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] Interfacing deal.ii for solution, pre and post-processing

2019-03-15 Thread Muhammad Mashhood
Dear all,
I am new to deal.ii and looking for a nice interfacing tool for 
making mesh import, BC application, solution and post-processing for 
simulation cases etc. easy for me. Can anyone give me suggestion regarding 
this? 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.