Re: [deal.II] Q: Question about extracting part of a vector

2023-07-31 Thread Najwa Alshehri 
Hello Abbas,

Thank you for your response. I have actually written something, but I need
to test it. It would be great to have a look at your work as well, so we
can compare.

Best regards,
Najwa

On Mon, 31 Jul 2023 at 10:48 PM Abbas Ballout 
wrote:

> Najwaa,
>
> I submitted a pull request 
> recently about something similar
> . (I guess)
> Maybe that would help.
>
> Abbas
>
>
> On Monday, July 31, 2023 at 7:37:59 PM UTC+2 najwaa...@gmail.com wrote:
>
>> Dear Wolfgang,
>>
>> Thank you for your answer. I will try to write a patch to the deal.II
>> sources that implement the missing function. This might require some time.
>> I will come back here if needed.
>>
>>
>> Thank you all for your quick answers,
>> Najwa
>>
>> On Wednesday, July 26, 2023 at 11:41:15 PM UTC+3 Wolfgang Bangerth wrote:
>>
>>> On 7/26/23 12:17, Najwa Alshehri wrote:
>>> >
>>> > Regarding the function "VectorFucntionFromScalarFunctionObject," I
>>> have
>>> > observed that it works for computing the L2 norm of the error.
>>> However, when I
>>> > attempted to compute the H1_seminorm of the error, I noticed that the
>>> gradient
>>> > was not implemented for this function. Please let me know if my
>>> understanding
>>> > is incorrect, as I referred to the  for this.
>>>
>>> Yes, correct. Someone needs to implement
>>> VectorFucntionFromScalarFunctionObject::gradient()
>>> and/or
>>> VectorFucntionFromScalarFunctionObject::gradient_list()
>>> in exactly the same way as the value() and value_list() functions are
>>> implemented.
>>>
>>>
>>> > Could you kindly advise me on the simplest way to accomplish this?
>>>
>>> The easiest way is to create a class derived from
>>> VectorFucntionFromScalarFunctionObject in your own project that
>>> implements the
>>> missing function. The better way is to write a patch to the deal.II
>>> sources
>>> that implements the missing function because then others can use your
>>> work in
>>> the future as well :-)
>>>
>>>
>>> > On a side note, although "VectorFucntionFromScalarFunctionObject"
>>> works with
>>> > the L2 norm of the error, it is quite computationally intensive.
>>>
>>> It isn't VectorFucntionFromScalarFunctionObject that's expensive, but
>>> the
>>> FEFieldFunction. That's sort of inherently the case with this class. If
>>> you
>>> can, it should be avoided and you should try an evaluate the FE field
>>> you have
>>> at regular quadrature points, via FEValues.
>>>
>>> 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 a topic in the
> Google Groups "deal.II User Group" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dealii/DqH2auneWaY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> dealii+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/dealii/dd5f93f8-fb58-45c6-9ab2-91ef6c5bdf56n%40googlegroups.com
> 
> .
>

-- 
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/CABQM8dT6n4f2r-Efj4XR%3DegyzXPW9UtY3Z9_vxiX1MeUhKNLWg%40mail.gmail.com.

Re: [deal.II] Q: Question about extracting part of a vector

2023-07-31 Thread Abbas Ballout 
Najwaa, 

I submitted a pull request  
recently about something similar 
. (I guess)
Maybe that would help. 

Abbas 
 

On Monday, July 31, 2023 at 7:37:59 PM UTC+2 najwaa...@gmail.com wrote:

> Dear Wolfgang,
>
> Thank you for your answer. I will try to write a patch to the deal.II 
> sources that implement the missing function. This might require some time. 
> I will come back here if needed.
>
>
> Thank you all for your quick answers,
> Najwa
>
> On Wednesday, July 26, 2023 at 11:41:15 PM UTC+3 Wolfgang Bangerth wrote:
>
>> On 7/26/23 12:17, Najwa Alshehri wrote: 
>> > 
>> > Regarding the function "VectorFucntionFromScalarFunctionObject," I have 
>> > observed that it works for computing the L2 norm of the error. However, 
>> when I 
>> > attempted to compute the H1_seminorm of the error, I noticed that the 
>> gradient 
>> > was not implemented for this function. Please let me know if my 
>> understanding 
>> > is incorrect, as I referred to the  for this. 
>>
>> Yes, correct. Someone needs to implement 
>> VectorFucntionFromScalarFunctionObject::gradient() 
>> and/or 
>> VectorFucntionFromScalarFunctionObject::gradient_list() 
>> in exactly the same way as the value() and value_list() functions are 
>> implemented. 
>>
>>
>> > Could you kindly advise me on the simplest way to accomplish this? 
>>
>> The easiest way is to create a class derived from 
>> VectorFucntionFromScalarFunctionObject in your own project that 
>> implements the 
>> missing function. The better way is to write a patch to the deal.II 
>> sources 
>> that implements the missing function because then others can use your 
>> work in 
>> the future as well :-) 
>>
>>
>> > On a side note, although "VectorFucntionFromScalarFunctionObject" works 
>> with 
>> > the L2 norm of the error, it is quite computationally intensive. 
>>
>> It isn't VectorFucntionFromScalarFunctionObject that's expensive, but the 
>> FEFieldFunction. That's sort of inherently the case with this class. If 
>> you 
>> can, it should be avoided and you should try an evaluate the FE field you 
>> have 
>> at regular quadrature points, via FEValues. 
>>
>> 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/dd5f93f8-fb58-45c6-9ab2-91ef6c5bdf56n%40googlegroups.com.

Re: [deal.II] Q: Question about extracting part of a vector

2023-07-31 Thread Najwa Alshehri 
Dear Wolfgang,

Thank you for your answer. I will try to write a patch to the deal.II 
sources that implement the missing function. This might require some time. 
I will come back here if needed.


Thank you all for your quick answers,
Najwa

On Wednesday, July 26, 2023 at 11:41:15 PM UTC+3 Wolfgang Bangerth wrote:

> On 7/26/23 12:17, Najwa Alshehri wrote:
> > 
> > Regarding the function "VectorFucntionFromScalarFunctionObject," I have 
> > observed that it works for computing the L2 norm of the error. However, 
> when I 
> > attempted to compute the H1_seminorm of the error, I noticed that the 
> gradient 
> > was not implemented for this function. Please let me know if my 
> understanding 
> > is incorrect, as I referred to the  for this.
>
> Yes, correct. Someone needs to implement
> VectorFucntionFromScalarFunctionObject::gradient()
> and/or
> VectorFucntionFromScalarFunctionObject::gradient_list()
> in exactly the same way as the value() and value_list() functions are 
> implemented.
>
>
> > Could you kindly advise me on the simplest way to accomplish this?
>
> The easiest way is to create a class derived from 
> VectorFucntionFromScalarFunctionObject in your own project that implements 
> the 
> missing function. The better way is to write a patch to the deal.II 
> sources 
> that implements the missing function because then others can use your work 
> in 
> the future as well :-)
>
>
> > On a side note, although "VectorFucntionFromScalarFunctionObject" works 
> with 
> > the L2 norm of the error, it is quite computationally intensive.
>
> It isn't VectorFucntionFromScalarFunctionObject that's expensive, but the 
> FEFieldFunction. That's sort of inherently the case with this class. If 
> you 
> can, it should be avoided and you should try an evaluate the FE field you 
> have 
> at regular quadrature points, via FEValues.
>
> 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/e1aa5c5a-46cc-417b-89d5-c1bbfd47a641n%40googlegroups.com.

[deal.II] deal.II Newsletter #262

2023-07-31 Thread 'Rene Gassmoeller' via deal.II User Group 
Hello everyone!

This is deal.II newsletter #262.
It automatically reports recently merged features and discussions about the 
deal.II finite element library.


## Below you find a list of recently proposed or merged features:

#15807: MGTwoLevelTransfer: specialize setup for FCP and p-mg (proposed by 
peterrum) https://github.com/dealii/dealii/pull/15807

#15806: Add NodeVisitor in rtree.h (proposed by fdrmrc) 
https://github.com/dealii/dealii/pull/15806

#15805: Added gradient() evaluation to VectorFunctionFromTensorFunction 
(proposed by AbbBallout) https://github.com/dealii/dealii/pull/15805

#15803: NonMatching:  Add support for FE_Q_iso_Q1 to MeshClassifier and 
Discrete(Face)QuadratureGenerator (proposed by bergbauer) 
https://github.com/dealii/dealii/pull/15803

#15802: Adjust expectations in a GridTools::get_coarse_mesh_description(). 
(proposed by bangerth) https://github.com/dealii/dealii/pull/15802

#15801: Make GridGenerator::hyper_cube_with_cylindrical_hole<2>() more robust. 
(proposed by bangerth) https://github.com/dealii/dealii/pull/15801

#15800: AffineConstraints: fix warnings (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/15800

#15799: trilinos_sparse_matrix_mmult needs EpetraExt (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/15799

#15798: Fix block_vector_vector_assign (proposed by masterleinad; merged) 
https://github.com/dealii/dealii/pull/15798

#15797: DataOut::add_mg_data_vector(): copy vector and update ghost values 
(proposed by peterrum; merged) https://github.com/dealii/dealii/pull/15797

#15796: Simplify code using structured bindings. (proposed by bangerth; merged) 
https://github.com/dealii/dealii/pull/15796

#15795: Minor addition to the documentation of a GridTools function. (proposed 
by bangerth; merged) https://github.com/dealii/dealii/pull/15795

#15794: Use MGTransferGlobalCoarsening also for local smoothing (proposed by 
peterrum) https://github.com/dealii/dealii/pull/15794

#15793: `MGTransferMF::interpolate_to_mg()`: zero out ghost values (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/15793

#15792: Add MGLevelObject::clear() (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/15792

#15791: Fix timing_step_37.cc (proposed by masterleinad; merged) 
https://github.com/dealii/dealii/pull/15791

#15789: Pre-compute what's needed for AffineConstraints::distribute(). 
(proposed by bangerth) https://github.com/dealii/dealii/pull/15789

#15788: [9.5] Allow compilation with PETSc but without MPI. (proposed by 
bangerth; merged) https://github.com/dealii/dealii/pull/15788

#15787: Require PETSc to be configured with MPI support (proposed by 
masterleinad) https://github.com/dealii/dealii/pull/15787

#15785: PETScWrappers::TimeStepper support resizing while solving (proposed by 
stefanozampini) https://github.com/dealii/dealii/pull/15785

#15784: Replace MGTransferMG usages in tests/matrix_free (proposed by peterrum; 
merged) https://github.com/dealii/dealii/pull/15784

#15783: More work to replace std::*::type by std::*_t. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/15783

#15782: MGLevelGlobalTransfer: remove unused variables (proposed by peterrum; 
merged) https://github.com/dealii/dealii/pull/15782

#15781: Allow compilation with PETSc but without MPI. (proposed by bangerth; 
merged) https://github.com/dealii/dealii/pull/15781

#15779: Small modifications to performance/timing_matrix_free_kokkos (proposed 
by peterrum; merged) https://github.com/dealii/dealii/pull/15779

#15777: CudaWrappers::MatrixFree: Only create required host mirrors (proposed 
by masterleinad; merged) https://github.com/dealii/dealii/pull/15777

#15776: Use MPILogInitAll in particles/generators_* tests (proposed by 
masterleinad; merged) https://github.com/dealii/dealii/pull/15776

#15775: CMake: only use REPEAT for >=3.15 (proposed by peterrum; merged) 
https://github.com/dealii/dealii/pull/15775

#15773: Draft of FECouplingValues. (proposed by luca-heltai) 
https://github.com/dealii/dealii/pull/15773

#15772: Allow configuring with CMAKE_CXX_STANDARD=23 (proposed by masterleinad; 
merged) https://github.com/dealii/dealii/pull/15772

#15771: Add performance test for `CUDAWrapper::MatrixFree` (proposed by 
peterrum; merged) https://github.com/dealii/dealii/pull/15771

#15770: Config.h.in: use PETSc/SLEPc macros to determine PETSc/SLEPc version 
(proposed by stefanozampini; merged) https://github.com/dealii/dealii/pull/15770

#15769: Update PETScWrappers::NonlinearSolver (proposed by stefanozampini; 
merged) https://github.com/dealii/dealii/pull/15769

#15768: PETScWrappers: Support with-strict-petscerrorcode configurations 
(proposed by stefanozampini; merged) https://github.com/dealii/dealii/pull/15768

#15767: tweak PETSc tests (proposed by stefanozampini; merged) 
https://github.com/dealii/dealii/pull/15767

#15766: [C++17] Prefer std::is_*_v over std::is_*::value. (proposed by