Re: [deal.II] Step-29

[Wolfgang Bangerth]

Muhammad,

> When we get the solution of Helmoltz equation using the function 
> UltrasoundProblem::solve ()
> [...]
> 
> The output solution will be alpha and Beta from the function 
> UltrasoundProblem::solve (). It will become of the input of the class
> class ComputeIntensity : public DataPostprocessorScalar 
> .
> Using this class we will calculate the uh, duh, dduh etc.
> Anyone can explain to me how it is calculating the uh? I don't understand 
> what 
> is the input to this class after calculating the coeeficients Alpha nad Beta 
> in the tutorial.

The input uh to ComputeIntensity::compute_derived_quantities_vector() *is* the 
solution at the points where we want to create output. You don't need to 
compute it.

uh is of type std::vector >. Specifically, the outer vector is 
over all of the points on one cell where we want to create output; the inner 
vector will, in your case, have size 2 and contain the pairs {alpha, beta} at 
the output point.

I hope this makes it clear why the implementation of the function makes sense!

Best
W.


-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/40516218-b971-948b-3ed4-867508bbea67%40colostate.edu.

Re: [deal.II] how to get the transpose of a block sparsity matrix?

[Wolfgang Bangerth]

On 8/16/19 9:41 PM, hua zhang wrote:
>          I am studying goal oriented adaptivity for FSI problems and code it 
> in deal.ii. The system consists of velocity, pressure, displacement(u,p,w), 
> so  I use block sparsity matrix for system matrix. When I solve the dual 
> equation, I find what I need is a transpose matrix of system matrix, so how 
> should I do to get the transpose of block sparsity matrix?
>          I have tried to get transpose of every block using 
> transpose_operator, but I don't know how to combined these terms into a new 
> block sparsity matrix.

In essence, you only need an object whose vmult function calls the Tvmult 
function of your block sparse matrix. That can be achieved with only a few 
lines of code. But I think it can be done in an even easier way: create a 
LinearOperator object from your block matrix, and then apply transpose() to it 
to get the transpose linear operator.

Best
  W.

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/348c5b2b-2906-bcfd-fcd2-69016f5dcf97%40colostate.edu.

Re: [deal.II] When Lame and nu are big number, the result is always zero.

[Wolfgang Bangerth]

On 8/17/19 2:49 AM, 张嘉宁 wrote:
> I am the new one here, and recently I test a program solving elastic problem 
> considering neumann boundary conditions. So I finish  it on the basis of 
> Step-17 by adding the neumann boundary conditions. I found that wen lame and 
> mu are not large (i.e.  equals to 1 by default), the solution seems right. 
> But 
> when I set the lame and mu to the parameters of stell, the solutions is 
> always 
> zero. Interesting, if the lame and mu are not so large, part of the solution 
> is zero but the other part is not. Anyone know the reason?

Is the solution exactly equal to zero, or just small?

It does make sense that if the parameters become large, the deformation 
becomes small if you keep the force the same: after all, if you apply a bit of 
force to a pillow made of cloth, you will get a deformation of a few 
centimeters. If the pillow were made of steal, you'd get a deformation of only 
a few micrometers.

Best
  W.

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/3416d1a2-dc06-7f9e-e54e-1ca4a75d0a9e%40colostate.edu.

Re: [deal.II] Parallel distributed hp solution transfer

[Wolfgang Bangerth]

Doug,

> I am trying to use the parallel::distributed::SolutionTransfer LinearAlgebra::distributed::Vector, hp::DoFHandler> class and I 
> can't seem to use it similarly to the serial version.
> 
> I looked through the tests/distributed_grids/solution_transfer_0*.cc tests 
> and 
> none of them seem to be testing for the hp refinement.

Correct. The hp case wasn't implemented so far, but most of it made it into 
the 9.1 release. Some of it only happened on the master branch after the 
release, so I would suggest that that's what you should be working with.

I don't recall which tests you should look at, but this functionality was 
implemented by Marc Fehling, so I'm CC:ing him here.

Best
  W.

-- 

Wolfgang Bangerth  email: bange...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/56801645-f1ae-c0dc-6a74-a1ac4fea8f0c%40colostate.edu.

[deal.II] When Lame and nu are big number, the result is always zero.

[张嘉宁]

Hi,
I am the new one here, and recently I test a program solving elastic 
problem considering neumann boundary conditions. So I finish  it on the 
basis of Step-17 by adding the neumann boundary conditions. I found that 
wen lame and mu are not large (i.e.  equals to 1 by default), the solution 
seems right. But when I set the lame and mu to the parameters of stell, the 
solutions is always zero. Interesting, if the lame and mu are not so large, 
part of the solution is zero but the other part is not. Anyone know the 
reason?

Thanks for your time!   

-- 
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/90647de9-0490-4231-ad65-1bf530db9c5a%40googlegroups.com.

[deal.II] Parallel distributed hp solution transfer

[Doug]

Hello,

I am trying to use the parallel::distributed::SolutionTransfer, hp::DoFHandler> class and 
I can't seem to use it similarly to the serial version.

I looked through the tests/distributed_grids/solution_transfer_0*.cc tests 
and none of them seem to be testing for the hp refinement. The code I'm 
working on might be a bit large. Instead, I recreated the errors by copying 
the tests/hp/solution_transfer.cc, which contains SolutionTransfer for hp, 
and modified it to use the parallel distributed version of it.

Please find attached a proposed test. Line 160-175 are commented out and 
does the p-refinement. Therefore, the error below is for h-refinement only, 
but with an hp object. Oddly enough, my code works fine for h-refinement, 
but I get the same error below when I do p-refinement.

110: 
110: An error occurred in line <401> of file 
 in 
function
110: void dealii::parallel::distributed::SolutionTransfer::unpack_callback(const typename 
dealii::parallel::distributed::Triangulation::cell_iterator&, typename 
dealii::parallel::distributed::Triangulation::CellStatus, const 
boost::iterator_range<__gnu_cxx::__normal_iterator > > >&, std::vector&) 
[with int dim = 2; VectorType = 
dealii::LinearAlgebra::distributed::Vector; DoFHandlerType = 
dealii::hp::DoFHandler<2, 2>; typename 
dealii::parallel::distributed::Triangulation::cell_iterator = 
dealii::TriaIterator >; typename 
dealii::parallel::distributed::Triangulation::CellStatus = dealii::Triangulation<2, 2>::CellStatus]
110: The violated condition was: 
110: dof_handler->get_fe(fe_index).dofs_per_cell == it_dofvalues->size()
110: Additional information: 
110: The transferred data was packed with a different number of dofs 
than thecurrently registered FE object assigned to the DoFHandler has.
110: 

Now, if I uncomment those lines, and therefore do p-refinement in the 
attached test, I get

110: 
110: An error occurred in line <382> of file 
 in 
function
110: void dealii::parallel::distributed::SolutionTransfer::unpack_callback(const typename 
dealii::parallel::distributed::Triangulation::cell_iterator&, typename 
dealii::parallel::distributed::Triangulation::CellStatus, const 
boost::iterator_range<__gnu_cxx::__normal_iterator > > >&, std::vector&) 
[with int dim = 2; VectorType = 
dealii::LinearAlgebra::distributed::Vector; DoFHandlerType = 
dealii::hp::DoFHandler<2, 2>; typename 
dealii::parallel::distributed::Triangulation::cell_iterator = 
dealii::TriaIterator >; typename 
dealii::parallel::distributed::Triangulation::CellStatus = dealii::Triangulation<2, 2>::CellStatus]
110: The violated condition was: 
110: cell->child(child_index)->active_fe_index() == fe_index
110: Additional information: 
110: This exception -- which is used in many places in the library -- 
usually indicates that some condition which the author of the code thought 
must be satisfied at a certain point in an algorithm, is not fulfilled. An 
example would be that the first part of an algorithm sorts elements of an 
array in ascending order, and a second part of the algorithm later 
encounters an element that is not larger than the previous one.
110: 
110: There is usually not very much you can do if you encounter such an 
exception since it indicates an error in deal.II, not in your own program. 
Try to come up with the smallest possible program that still demonstrates 
the error and contact the deal.II mailing lists with it to obtain help.
110: 

I went through some of the deal.II source code and it's a bit out of my 
depth. Please let me know if I am somehow not p-refining correctly, or if I 
can be of any help to fix this.

Best regards,

Doug

-- 
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/1836ac96-4f6c-4d90-ad2f-5e68cbabe623%40googlegroups.com.
// -
//
// Copyright (C) 1998 - 2018 by the deal.II authors
//
// This file is part of the deal.II library.
//
// The deal.II library is free software; you can use it, redistribute
// it, and/or modify it under the terms of the GNU Lesser General
// Public License as published by the Free Software Foundation; either
// version 2.1 of the License, or (at your option) any later version.
// The full text of the license can be found in the file LICENSE.md at
// the top level directory of deal.II.
//
//