[deal.II] Classical returning mapping algorithm for plasticity in deal.ii
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
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&data=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595&sdata=CQSVVYYrHp5wMfy3INtkJBdS%2BNjFzBqLAdPwVHI1r%2FU%3D&reserved=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&data=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138637595&sdata=Y9F5eICnrFT8jNpnmg03tO3gb%2BWO%2B8xEqt9%2F9fucTBQ%3D&reserved=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&data=02%7C01%7CWolfgang.Bangerth%40colostate.edu%7Cd00ea92f27a5466d8a5e08d8395d0f41%7Cafb58802ff7a4bb1ab21367ff2ecfc8b%7C0%7C0%7C637322419138647592&sdata=7ZHhT3M4M%2Bu2FaPwpR2qwSkJevjIip4d7%2BvaQrqmsG0%3D&reserved=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
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
Re: [deal.II] Output of Gauss point stress tensor
* iter->set_properties (make_array_view(interpolatedParticleQuantities.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
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
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
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
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
Re: [deal.II] Re: step-42 now available
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
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
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
Hi! Andrew. I would not say it is giving wrong results because the objective for which it is written is being well fulfilled. But for my application, I need the output of plastic strains, plastic flow and hardening coefficients values along with the isotropic plastic hardening. As well as storing the history of the plastic strains or displacement in the cells when even the load is removed. Moreover the temperature dependent material properties are also there so I thought step-42 would not be enough for me by now and need something new and a bit advanced. On Thursday, November 21, 2019 at 7:09:26 PM UTC+1, mac wrote: > > Are you sure that the existing plasticity code (step-42) is behaving > incorrectly? Can you demonstrate this via a simple example (consider only > the mechanical problem)? I find this conclusion very surprising. > > Best > Andrew > > > On 21 Nov 2019, at 18:02, 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 dea...@googlegroups.com . > > To view this discussion on the web visit > https://groups.google.com/d/msgid/dealii/0a1abe45-f8a1-025e-edcf-419afce8b3ee%40colostate.edu. > > > > -- 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/f29e7815-d1f5-418d-ae1d-6b6ae384a59b%40googlegroups.com.
Re: [deal.II] small strain (additive strain decomposition) elastoplastic code
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
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
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
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
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 "
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 "
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 "
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 "
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> &input, ^/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> &input,* 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 &g
[deal.II] running the "The 'Goal-oriented mesh adaptivity in elastoplasticity problems' code gallery program "
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
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
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
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
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
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
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
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
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
dir/step-26.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
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
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
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 &p,
const unsigned int component = 0) const;
private:
const double period;
};
template
double RightHandSide::value (const Point &p,
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 &p,
> > 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
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
&p,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
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 > &points, // the
> active
> > cell is also imported when right hand side is called to induce some
> Neumann BC
> > std::vector > &values,
> > 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
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 > &points, // the
active cell is also imported when right hand side is called to induce some
Neumann BC
std::vector > &values,
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
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
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.
