geopdes-users Mailing List for GeoPDEs (moved to GitHub)

Dear GeoPDEs users,
after quite some time, I am happy to announce that a new version of 
GeoPDEs has been released. The new version contains the following features:

  * C1 splines over analysis-suitable G1 multipatch domains (thanks to
    Cesare Bracco and Andrea Farahat).
  * Hierarchical C1 splines over analysis-suitable G1 multipatch domains
    (thanks to Cesare Bracco, and also to Andrea Farahat).
  * Examples for hierarchical C1 splines on multipatch domains for
    bilaplacian equation and Kirchhoff-Love shells (thanks to Cesare
    Bracco and Andrea Farahat, and also to Giuliano Guarino).
  * Cahn-Hilliard equation with adaptive refinement and coarsening on
    single patch domains (thanks to Michele Torre).
  * Cahn-Hilliard equation with adaptive refinement and coarsening on
    multipatch domains (thanks to Michele Torre and Cesare Bracco).

As usual, you can download GeoPDEs from its webpage:
https://rafavzqz.github.io/geopdes/

The source code of GeoPDEs is available on the GitHub repository. The 
repository for adaptive methods with hierarchical splines has also been 
made public.
https://github.com/rafavzqz/geopdes
https://github.com/rafavzqz/geopdes_hierarchical

Best regards,
Rafael Vazquez

Dear GeoPDEs users,
after quite some time, I am happy to announce that a new version of 
GeoPDEs has been released. The new version contains the following features:

  * C1 splines over analysis-suitable G1 multipatch domains (thanks to
    Cesare Bracco and Andrea Farahat).
  * Hierarchical C1 splines over analysis-suitable G1 multipatch domains
    (thanks to Cesare Bracco, and also to Andrea Farahat).
  * Examples for hierarchical C1 splines on multipatch domains for
    bilaplacian equation and Kirchhoff-Love shells (thanks to Cesare
    Bracco and Andrea Farahat, and also to Giuliano Guarino).
  * Cahn-Hilliard equation with adaptive refinement and coarsening on
    single patch domains (thanks to Michele Torre).
  * Cahn-Hilliard equation with adaptive refinement and coarsening on
    multipatch domains (thanks to Michele Torre and Cesare Bracco).

As usual, you can download GeoPDEs from its webpage:
https://rafavzqz.github.io/geopdes/

The source code of GeoPDEs is available on the GitHub repository. The 
repository for adaptive methods with hierarchical splines has also been 
made public.
https://github.com/rafavzqz/geopdes
https://github.com/rafavzqz/geopdes_hierarchical

Best regards,
Rafael Vazquez

Hello !

Geopde looks great and a colleaague of mine confirmed.

I wanted to know if there exist any function to import step files or other
cad formats and convert them in the proper nurbs format?

I want to use a real cad case but i am stuck right now

Thanks in advance!

Cédric

Hi Guilherme,
unfortunately, the generation of VTK files in GeoPDEs is not very good. 
I would like to update it at some point to use the new functionality for 
splines in VTK, but I don't have enough time.

I understant that your thickness is constant on each element. If so, a 
possible workaround is to first define the space of piecewise constants, 
that you can easily define with sp_bspline. The number of dofs of the 
space is equal to the number of elements, so you can also define a field 
with one value per element.

Then, to export the VTK file, use the knots repeated twice, and slightly 
shifted to the left and right. For instance, if you have the knot vector 
[0 0.25 0.5 0.75 1], you could use the vtk points [0 0.25-ep 0.25+ep 
0.5-ep 0.5+ep 0.75-ep 0.75+ep 1], with a value of ep=1e-12, or similar.

Of course, you will need to do it in the two directions, and use a cell 
array instead of an array.

I have never used it myself, so I don't really know how this will work.

Best,
Rafa

On 12/1/24 20:44, Guilherme Henrique da Silva wrote:
> Hi Rafa, I'm trying to save a VTK, but I have information for each element
> (shell element thickness) instead of a solution field, which is the main
> information that is written in the sp_to_vtk function.
> I supposed we don't have a secret knotspans_to_vtk function? 😅
>
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Hi Rafa, I'm trying to save a VTK, but I have information for each element
(shell element thickness) instead of a solution field, which is the main
information that is written in the sp_to_vtk function.
I supposed we don't have a secret knotspans_to_vtk function? 😅

Dear Yangpeng,
there was a similar question by Ganesh a couple of years ago. He needed 
vector-valued coefficients, but the same kind of modification should 
apply if you want a matrix-valued coefficient.
https://sourceforge.net/p/geopdes/mailman/message/37226011/
https://sourceforge.net/p/geopdes/mailman/message/37225854/

Please, read carefully the reply I gave to him. If you have any doubts 
or need more details, feel free to send your question to the mailing list.

Best regards,
Rafael

On 12/12/23 18:56, Yangpeng Zhang wrote:
> Hello Dr.Vazquez,
>
> I hope this email finds you well. I am a graduate student Yangpeng Zhang in UNLV learning how to use your GeoPDE package currently.
>
> Here is the question I have. I want to know how to use op_u_v_tp(space_A,space_B,msh,coeff) for vector space A and B when one has a (matrix or vectorial) coefficient function exactly (instead of just constant coefficient).
>
>
> Any response will be appreciated.
>
> Have a nice day!
> Best,
> Yangpeng
>
>
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Hello Dr.Vazquez,

I hope this email finds you well. I am a graduate student Yangpeng Zhang in UNLV learning how to use your GeoPDE package currently.

Here is the question I have. I want to know how to use op_u_v_tp(space_A,space_B,msh,coeff) for vector space A and B when one has a (matrix or vectorial) coefficient function exactly (instead of just constant coefficient).


Any response will be appreciated.

Have a nice day!
Best,
Yangpeng

Hi Guilherme,
I didn't get the working example, but I think I know what is the problem.

Your understanding of the "precompute" and "element_list" functions may 
be correct. Have you tried to do the same with other matrices? For 
instance, with the usual mass matrix (op_u_v_tp) or stiffness matrix 
(op_su_ev_tp) you should get the correct result.

So, what is different about op_KL_shells_tp? If you look at the code, 
lines 42-44, we compute the parametrization as usual, but the basis 
functions are computed in the parametric domain (sp_evaluate_col_param). 
We take care of the mapping later inside op_KL_shells. So, to recover 
the correct matrix you will need to use the functions 
sp_evaluate_element_list_param, or sp_precompute_param.

I didn't implement the Kirchhoff-Love shells myself, so I don't know 
exactly the details. You can probably get more information in the theses 
of Josef Kiendl (who applied it for the first time) and Luca Coradello 
(who implemented it in GeoPDEs).

Best,
Rafa

On 12/9/23 17:09, Guilherme Henrique da Silva wrote:
> Hi Rafa. I'm currently working on a subject that requires the elementary
> matrices to be calculated separately and assembled afterwards., However,
> I've run into the issue that the matrices assembled are different!
>
> I have assembled K = op_KL_shells_tp() from the Kirchoff-Love Shells
> operators. This is how my matrices should be in the end.
> By doing msh_precompute and sp_precompute (or element_list, the result is
> the same), I couldn't  assembled the same matrix using K_new =
> op_KL_shells, as the results greatly vary.
>
> I believe my understanding of the precompute and element_list might be
> wrong, as I expected the operator to return the matrix correctly.
>
> I've attached a code with a working example for reference.
>
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Hi Rafa. I'm currently working on a subject that requires the elementary
matrices to be calculated separately and assembled afterwards., However,
I've run into the issue that the matrices assembled are different!

I have assembled K = op_KL_shells_tp() from the Kirchoff-Love Shells
operators. This is how my matrices should be in the end.
By doing msh_precompute and sp_precompute (or element_list, the result is
the same), I couldn't  assembled the same matrix using K_new =
op_KL_shells, as the results greatly vary.

I believe my understanding of the precompute and element_list might be
wrong, as I expected the operator to return the matrix correctly.

I've attached a code with a working example for reference.

Dear Philipp,
I'm glad it was helpful, and I will be glad to meet you in Lyon.

Best,
Rafa

On 25.04.23 16:48, Philipp Zilk wrote:
> Dear Rafa,
>
>
> you are completely right, we have to be particularly careful when 
> considering the error of eigenfunctions.
>
> I was implementing your option number 1) today and it works perfectly. 
> The part with the constructor was exactly what we needed here. Your 
> hint that it is better to use the finest mesh for a higher accuracy is 
> very useful as well.
>
> Thank you so much for your fast and precise advice, you really helped 
> us a lot! I wish you a great week and hope to maybe meet you in person 
> in Lyon :-)
>
>
> Best regards
> Philipp
>
>
>
> On 25.04.23 12:29, Rafael Vazquez wrote:
>> Dear Philipp,
>> first of all, a general comment. One has to be careful when computing
>> the error of eigenfunctions: if (lambda, u) is an eigenpair, also
>> (lambda, -u) is. You will have to check that you are comparing the
>> correct solutions. The things will become even more complicated if
>> lambda has multiplicity greater than one: if (lambda, u_1) and
>> (lambda_u_2) are valid eigenpairs, any linear combination of u_1 and u_2
>> will be an eigenfunction associated to lambda.
>>
>> That being said, let us focus on the GeoPDEs part. I see two different
>> ways of computing the error with respect to a reference solution in a
>> finer mesh: 1) evaluate both solutions at the quadrature points of the
>> same mesh, or 2) express your coarse solution in terms of the basis
>> functions of the fine space.
>>
>> 1) This is basically what you were trying to do. You can evaluate a
>> space on a different mesh using the constructor. For instance:
>> sp_coarse_on_fine_mesh = space_coarse.constructor (msh_fine);
>>
>> After that, you can use "sp_eval_msh" (after creating the structures
>> with *_precompute or *_evaluate_col) to evaluate you solution on the
>> mesh. You will also need to create a new function, similar to
>> "sp_h1_error", to use as input the reference solution (and its space).
>> To compute the errors, I recommend you to always use the finest mesh,
>> not the coarse one, to get better accuracy.
>>
>> 2) If the spaces are nested, you can express the solution of the coarse
>> space as linear combinations of the basis functions of the fine one. For
>> instance, you can compute the refinement matrix from the second output
>> of the function "sp_refine", applying the Kronecker product. Once you
>> have the refinement matrix (Rmat), it would be something like this:
>> u_fine = Rmat * u_coarse;
>> sp_h1_error (u_fine - u_ref, space_fine, msh_fine, uex, graduex)
>>
>> This has the advantage that you can reuse the function sp_h1_error
>> without changes. The drawbacks are that the refinement matrix is large,
>> it only works for nested spaces, and in GeoPDEs it has not been
>> implemented for p-refinement. So, I recommend you to use the first 
>> method.
>>
>> Best,
>> Rafa
>>
>> On 24.04.23 19:37, Philipp Zilk wrote:
>> > Dear Rafael,
>> >
>> > I am using GeoPDEs to solve some eigenvalue problems for which I do
>> > not know an analytical solution. Nevertheless, I would like to study
>> > the convergence orders of the eigenfunctions and eigenvalues with
>> > respect to the mesh size. As a replacement of the exact solution, I
>> > want to use a reference solution which I computed before using a very
>> > fine mesh.
>> >
>> > Regarding the eigenvalue error, this approach can be implemented
>> > easily and I obtain reasonable results as I just have to compare
>> > numbers. Unfortunately, for the eigenfunctions it is not as easy, as
>> > here I have to compare two discrete functions which have been computed
>> > on different meshes.
>> >
>> > I have gone through all your examples, but I did not find a comparable
>> > situation, the exact solution is usually known there. Furthermore, I
>> > have been trying to adopt the function sp_h1_error such that I can use
>> > it for this case. Here, I have tried two different approaches without
>> > success:
>> >
>> > 1) Use the function sp_eval_msh to compute the values (and the values
>> > of the gradient) of the reference solution at the points given by the
>> > coarse mesh. From my impression, it seems like it is not possible to
>> > call this function using a space object (here: the fine space) and a
>> > mesh object (here: the coarse mesh) as input parameters which do not
>> > originate from the same solution process.
>> > 2) Use the function sp_eval to evaluate the reference solution (and
>> > the gradient) at the points given by the cell x. Here, I encountered
>> > the problem that sp_eval evaluates the computed solution in a
>> > Cartesian grid of points in the parametric domain and not for a list
>> > of given points in the physical domain.
>> >
>> > As I am slowly running out of ideas I would like to ask you if you
>> > know how this could be done best in GeoPDEs. Maybe my approaches are
>> > not going in the correct direction. I would be very thankful for any
>> > recommendations. Thank you very much for your time and your expertise!
>> >
>> > Best regards
>> > Philipp
>> >
>>
>
> -- 
> Philipp Zilk M.Sc.
> PhD Student
>
> Institute for Mathematics and Computer-Based Simulation (IMCS)
> University of the Bundeswehr Munich (UniBw M)
> D-85577 Neubiberg / Germany
>
> +49 (89) 6004 3408
> phi...@un...
> https://www.unibw.de/imcs-en

Dear Rafa,


you are completely right, we have to be particularly careful when 
considering the error of eigenfunctions.

I was implementing your option number 1) today and it works perfectly. 
The part with the constructor was exactly what we needed here. Your hint 
that it is better to use the finest mesh for a higher accuracy is very 
useful as well.

Thank you so much for your fast and precise advice, you really helped us 
a lot! I wish you a great week and hope to maybe meet you in person in 
Lyon :-)


Best regards
Philipp



On 25.04.23 12:29, Rafael Vazquez wrote:
> Dear Philipp,
> first of all, a general comment. One has to be careful when computing
> the error of eigenfunctions: if (lambda, u) is an eigenpair, also
> (lambda, -u) is. You will have to check that you are comparing the
> correct solutions. The things will become even more complicated if
> lambda has multiplicity greater than one: if (lambda, u_1) and
> (lambda_u_2) are valid eigenpairs, any linear combination of u_1 and u_2
> will be an eigenfunction associated to lambda.
>
> That being said, let us focus on the GeoPDEs part. I see two different
> ways of computing the error with respect to a reference solution in a
> finer mesh: 1) evaluate both solutions at the quadrature points of the
> same mesh, or 2) express your coarse solution in terms of the basis
> functions of the fine space.
>
> 1) This is basically what you were trying to do. You can evaluate a
> space on a different mesh using the constructor. For instance:
> sp_coarse_on_fine_mesh = space_coarse.constructor (msh_fine);
>
> After that, you can use "sp_eval_msh" (after creating the structures
> with *_precompute or *_evaluate_col) to evaluate you solution on the
> mesh. You will also need to create a new function, similar to
> "sp_h1_error", to use as input the reference solution (and its space).
> To compute the errors, I recommend you to always use the finest mesh,
> not the coarse one, to get better accuracy.
>
> 2) If the spaces are nested, you can express the solution of the coarse
> space as linear combinations of the basis functions of the fine one. For
> instance, you can compute the refinement matrix from the second output
> of the function "sp_refine", applying the Kronecker product. Once you
> have the refinement matrix (Rmat), it would be something like this:
> u_fine = Rmat * u_coarse;
> sp_h1_error (u_fine - u_ref, space_fine, msh_fine, uex, graduex)
>
> This has the advantage that you can reuse the function sp_h1_error
> without changes. The drawbacks are that the refinement matrix is large,
> it only works for nested spaces, and in GeoPDEs it has not been
> implemented for p-refinement. So, I recommend you to use the first method.
>
> Best,
> Rafa
>
> On 24.04.23 19:37, Philipp Zilk wrote:
> > Dear Rafael,
> >
> > I am using GeoPDEs to solve some eigenvalue problems for which I do
> > not know an analytical solution. Nevertheless, I would like to study
> > the convergence orders of the eigenfunctions and eigenvalues with
> > respect to the mesh size. As a replacement of the exact solution, I
> > want to use a reference solution which I computed before using a very
> > fine mesh.
> >
> > Regarding the eigenvalue error, this approach can be implemented
> > easily and I obtain reasonable results as I just have to compare
> > numbers. Unfortunately, for the eigenfunctions it is not as easy, as
> > here I have to compare two discrete functions which have been computed
> > on different meshes.
> >
> > I have gone through all your examples, but I did not find a comparable
> > situation, the exact solution is usually known there. Furthermore, I
> > have been trying to adopt the function sp_h1_error such that I can use
> > it for this case. Here, I have tried two different approaches without
> > success:
> >
> > 1) Use the function sp_eval_msh to compute the values (and the values
> > of the gradient) of the reference solution at the points given by the
> > coarse mesh. From my impression, it seems like it is not possible to
> > call this function using a space object (here: the fine space) and a
> > mesh object (here: the coarse mesh) as input parameters which do not
> > originate from the same solution process.
> > 2) Use the function sp_eval to evaluate the reference solution (and
> > the gradient) at the points given by the cell x. Here, I encountered
> > the problem that sp_eval evaluates the computed solution in a
> > Cartesian grid of points in the parametric domain and not for a list
> > of given points in the physical domain.
> >
> > As I am slowly running out of ideas I would like to ask you if you
> > know how this could be done best in GeoPDEs. Maybe my approaches are
> > not going in the correct direction. I would be very thankful for any
> > recommendations. Thank you very much for your time and your expertise!
> >
> > Best regards
> > Philipp
> >
>

-- 
Philipp Zilk M.Sc.
PhD Student

Institute for Mathematics and Computer-Based Simulation (IMCS)
University of the Bundeswehr Munich (UniBw M)
D-85577 Neubiberg / Germany

+49 (89) 6004 3408
phi...@un...
https://www.unibw.de/imcs-en

Dear Philipp,
first of all, a general comment. One has to be careful when computing 
the error of eigenfunctions: if (lambda, u) is an eigenpair, also 
(lambda, -u) is. You will have to check that you are comparing the 
correct solutions. The things will become even more complicated if 
lambda has multiplicity greater than one: if (lambda, u_1) and 
(lambda_u_2) are valid eigenpairs, any linear combination of u_1 and u_2 
will be an eigenfunction associated to lambda.

That being said, let us focus on the GeoPDEs part. I see two different 
ways of computing the error with respect to a reference solution in a 
finer mesh: 1) evaluate both solutions at the quadrature points of the 
same mesh, or 2) express your coarse solution in terms of the basis 
functions of the fine space.

1) This is basically what you were trying to do. You can evaluate a 
space on a different mesh using the constructor. For instance:
sp_coarse_on_fine_mesh = space_coarse.constructor (msh_fine);

After that, you can use "sp_eval_msh" (after creating the structures 
with *_precompute or *_evaluate_col) to evaluate you solution on the 
mesh. You will also need to create a new function, similar to 
"sp_h1_error", to use as input the reference solution (and its space). 
To compute the errors, I recommend you to always use the finest mesh, 
not the coarse one, to get better accuracy.

2) If the spaces are nested, you can express the solution of the coarse 
space as linear combinations of the basis functions of the fine one. For 
instance, you can compute the refinement matrix from the second output 
of the function "sp_refine", applying the Kronecker product. Once you 
have the refinement matrix (Rmat), it would be something like this:
u_fine = Rmat * u_coarse;
sp_h1_error (u_fine - u_ref, space_fine, msh_fine, uex, graduex)

This has the advantage that you can reuse the function sp_h1_error 
without changes. The drawbacks are that the refinement matrix is large, 
it only works for nested spaces, and in GeoPDEs it has not been 
implemented for p-refinement. So, I recommend you to use the first method.

Best,
Rafa

On 24.04.23 19:37, Philipp Zilk wrote:
> Dear Rafael,
>
> I am using GeoPDEs to solve some eigenvalue problems for which I do 
> not know an analytical solution. Nevertheless, I would like to study 
> the convergence orders of the eigenfunctions and eigenvalues with 
> respect to the mesh size. As a replacement of the exact solution, I 
> want to use a reference solution which I computed before using a very 
> fine mesh.
>
> Regarding the eigenvalue error, this approach can be implemented 
> easily and I obtain reasonable results as I just have to compare 
> numbers. Unfortunately, for the eigenfunctions it is not as easy, as 
> here I have to compare two discrete functions which have been computed 
> on different meshes.
>
> I have gone through all your examples, but I did not find a comparable 
> situation, the exact solution is usually known there. Furthermore, I 
> have been trying to adopt the function sp_h1_error such that I can use 
> it for this case. Here, I have tried two different approaches without 
> success:
>
> 1) Use the function sp_eval_msh to compute the values (and the values 
> of the gradient) of the reference solution at the points given by the 
> coarse mesh. From my impression, it seems like it is not possible to 
> call this function using a space object (here: the fine space) and a 
> mesh object (here: the coarse mesh) as input parameters which do not 
> originate from the same solution process.
> 2) Use the function sp_eval to evaluate the reference solution (and 
> the gradient) at the points given by the cell x. Here, I encountered 
> the problem that sp_eval evaluates the computed solution in a 
> Cartesian grid of points in the parametric domain and not for a list 
> of given points in the physical domain.
>
> As I am slowly running out of ideas I would like to ask you if you 
> know how this could be done best in GeoPDEs. Maybe my approaches are 
> not going in the correct direction. I would be very thankful for any 
> recommendations. Thank you very much for your time and your expertise!
>
> Best regards
> Philipp
>

Dear Rafael,

I am using GeoPDEs to solve some eigenvalue problems for which I do not 
know an analytical solution. Nevertheless, I would like to study the 
convergence orders of the eigenfunctions and eigenvalues with respect to 
the mesh size. As a replacement of the exact solution, I want to use a 
reference solution which I computed before using a very fine mesh.

Regarding the eigenvalue error, this approach can be implemented easily 
and I obtain reasonable results as I just have to compare numbers. 
Unfortunately, for the eigenfunctions it is not as easy, as here I have 
to compare two discrete functions which have been computed on different 
meshes.

I have gone through all your examples, but I did not find a comparable 
situation, the exact solution is usually known there. Furthermore, I 
have been trying to adopt the function sp_h1_error such that I can use 
it for this case. Here, I have tried two different approaches without 
success:

1) Use the function sp_eval_msh to compute the values (and the values of 
the gradient) of the reference solution at the points given by the 
coarse mesh. From my impression, it seems like it is not possible to 
call this function using a space object (here: the fine space) and a 
mesh object (here: the coarse mesh) as input parameters which do not 
originate from the same solution process.
2) Use the function sp_eval to evaluate the reference solution (and the 
gradient) at the points given by the cell x. Here, I encountered the 
problem that sp_eval evaluates the computed solution in a Cartesian grid 
of points in the parametric domain and not for a list of given points in 
the physical domain.

As I am slowly running out of ideas I would like to ask you if you know 
how this could be done best in GeoPDEs. Maybe my approaches are not 
going in the correct direction. I would be very thankful for any 
recommendations. Thank you very much for your time and your expertise!

Best regards
Philipp

-- 
Philipp Zilk M.Sc.
PhD Student

Institute for Mathematics and Computer-Based Simulation (IMCS)
University of the Bundeswehr Munich (UniBw M)
D-85577 Neubiberg / Germany

+49 (89) 6004 3408
phi...@un...
https://www.unibw.de/imcs-en

Dear Tom,
without an example, I'm not sure to have understood your question. I 
guess that the unnecessary internal boundary you mention is the one that 
"closes" the ring, at angular coordinates 0 and 2*pi.

To remove the internal boundary, you need a periodic boundary condition 
that glues together the functions from both sides. The NURBS package 
does not contain this functionality, but you can add periodic conditions 
in geopdes, see the example in "solve_laplace". Another possibility is 
to use a multi-patch description.

If you use periodic conditions, you will need to be careful: the 
parametrization of the circle/ring uses C^0 functions, and is only C^1 
at that "internal boundary" (as for angles pi/2, pi, 3*pi/2). If you try 
to use periodic conditions with regularity higher than C^1, you may lose 
the approximation order.

I hope that was helpful, but if you were referring to other problem, 
please send an example.

Best,
Rafael

On 04.03.23 02:59, seeker via Geopdes-users wrote:
> Dear Rafael,
>
>
> I hope this email finds you well. I am sorry to bother you, but I wanted to ask for your advice on a problem I encountered while using the 'nrbrevolve' function in the nurbs package. Specifically, I am trying to construct a complete circular surface by revolving a straight line, but I have found that there are internal boundaries that may be detrimental to the approximation process. Additionally, when I use the 'nrbglue' function to "glue" two geometries together, I sometimes end up with an unnecessary internal boundary. I was wondering if you could offer any suggestions on how to eliminate these boundaries.
>
>
> Thank you so much for your time and expertise. Best wish to you.
>
>
> Sincerely,
>
>
> Tom 
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Dear Rafael,


I hope this email finds you well. I am sorry to bother you, but I wanted to ask for your advice on a problem I encountered while using the 'nrbrevolve' function in the nurbs package. Specifically, I am trying to construct a complete circular surface by revolving a straight line, but I have found that there are internal boundaries that may be detrimental to the approximation process. Additionally, when I use the 'nrbglue' function to "glue" two geometries together, I sometimes end up with an unnecessary internal boundary. I was wondering if you could offer any suggestions on how to eliminate these boundaries.


Thank you so much for your time and expertise. Best wish to you.


Sincerely,


Tom 

Dear Tom,
the operators are designed to work also for manifolds, and in principle 
everything should work directly. For example, the operator 
op_gradu_gradv_tp, in the case of manifolds, will use the surface gradient.

Inside op_gradu_gradv_tp, when you evaluate the gradient of basis 
functions (sp_evaluate_col) for a manifold, the output in 
space.shape_function_gradients is the surface gradient. The first two 
dimensions will be msh.rdim and msh.ndim (3 and 2, for your surface). 
You can see how it is computed inside sp_grad_preserving_transform.

You can see an example in "ex_laplace_beltrami.m", where we solve a 
problem for the Laplace-Beltrami operator on a manifold.

Best,
Rafael

On 03.02.23 07:59, seeker via Geopdes-users wrote:
> Dear Rafael,
>     I'm sorry I encountered some problems to disturb you When I use GeoPDEs 3.0 to solve PDEs on low dimensional manifolds (such as 3D surfaces), can the 'op_gradu_gradv_tp' function be used directly?  
>     Recently, I have dealt with some problems on manifolds and found that the  approximation effect is not ideal. Whether it is necessary to convert it into surface gradient，or GeoPDEs is compatible with this.
>
>
>    Hope to get your suggestions. Best wish to you.
>
>
>
> Deeply grateful,
> Your Tom.
>
>
> seeker
> 254...@qq...
>
>
>
>  
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Dear Rafael,
    I'm sorry I encountered some problems to disturb you When I use GeoPDEs 3.0 to solve PDEs on low dimensional manifolds (such as 3D surfaces), can the 'op_gradu_gradv_tp' function be used directly?  
    Recently, I have dealt with some problems on manifolds and found that the  approximation effect is not ideal. Whether it is necessary to convert it into surface gradient，or GeoPDEs is compatible with this.


   Hope to get your suggestions. Best wish to you.



Deeply grateful,
Your Tom.


seeker
254...@qq...



 

Dear Rafael,


Thank you for reminding me this mailing list.



I also found that the same change should be done for
'weights_coarse' after the last mail. Sorry for the 

incomplete expression in the last mail.



Looking forward to more amazing features in the next version!


Best regards,
Ting Pi

Dear Ting Pi,
please, in the future send your comments and questions to the mailing 
list of geopdes-users. Other users may benefit from that.

I think you are right, and the same change should be done for 
'weights_coarse', so line 115 should read:
       vals = vals .* weights_coarse(ind_coarse(cols)) ./ 
weights_fine(ind_fine(rows));

I will apply the change, and make it available in the next version. 
Thanks for finding the mistake!

Best regards,
Rafael

On 13.08.22 12:48, 皮霆 wrote:
> Prof. **Vázquez,
>
> I am sorry for disturbing you. I have a question about GeoPDEs.
>
> I think there is a mistake in 'subdivision_matrix_two_levels__.m' in 
> GeoPDEs 3.2.2.
> In line 115, 'weights_fine(rows)' should be replaced by 
> 'weights_fine(ind_fine(rows))'.
>
> Am I right?
>
> Best regards,
>
>                          Ting Pi
> **

Dear Philipp,
no, there is no function to refine using uniformly spaced control 
points. The main reason is that it is not the "standard" isogeometric 
setting: by using uniform control points, the parameterization changes 
at each refinement step. This is different from knot refinement (or 
degree elevation), which gives you the control points to maintain the 
same parameterization.

In any case, it is not difficult to modify the code to do it. In the 
function "solve_laplace_iso", after performing knot insertion 
(nrbkntins) in line 75 and before calling "geo_load", you can set the 
value of the control points manually by modifying nurbs.coefs. The 
number of control points is in nurbs.number, and the dimension of 
nurbs.coefs should not change.

Another alternative is that you refine the geometry outside 
"solve_laplace_iso", setting uniform control points for the geometry at 
each step, and then solve the problem without refining in 
"solve_laplace_iso".

I hope that was helpful. Best regards,
Rafael

On 12.07.22 14:37, Zilk, Philipp wrote:
> Dear Mr Vazquez,
>
>
>
> I am using the GeoPDEs code to study some spectral approximation properties of IGA and I have a question about the implemented refinement strategies. In Remark 2, chapter 5.1.2, of the paper
>
>
> J. A. Cottrell, A. Reali, Y. Bazilevs, and T. J. R. Hughes. "Isogeometric analysis of structural vibrations". In: Computer Methods in Applied Mechanics and Engineering 195.41-43 (2006), pp. 5257-5296. doi: https://doi.org/10.1016/j.cma.2005.09.027
>
>
> the authors mention to use uniformly spaced control points for a better approximation of the Laplace spectrum on the unit interval [0,1].
>
>
> As far as I understood, the standard function for refining which is used in the GeoPDEs code (kntrefine) does generally not lead to a uniform distribution of the control points for NURBS with order p>1.
>
> Is there by chance an easy way to employ a refinement strategy that ensures uniformly spaced control points?
>
>
> Thank you very much for your time. I am really grateful to be able to work with your code.
>
>
>
> With best regards
>
> Philipp Zilk
>
> Institute for Mathematics and Computer-Based Simulation (IMCS)
> University of the Bundeswehr Munich (UniBw M)
> D-85577 Neubiberg / Germany
>
> https://www.unibw.de/imcs-en
>
>
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Dear Mr Vazquez,



I am using the GeoPDEs code to study some spectral approximation properties of IGA and I have a question about the implemented refinement strategies. In Remark 2, chapter 5.1.2, of the paper


J. A. Cottrell, A. Reali, Y. Bazilevs, and T. J. R. Hughes. "Isogeometric analysis of structural vibrations". In: Computer Methods in Applied Mechanics and Engineering 195.41-43 (2006), pp. 5257-5296. doi: https://doi.org/10.1016/j.cma.2005.09.027


the authors mention to use uniformly spaced control points for a better approximation of the Laplace spectrum on the unit interval [0,1].


As far as I understood, the standard function for refining which is used in the GeoPDEs code (kntrefine) does generally not lead to a uniform distribution of the control points for NURBS with order p>1.

Is there by chance an easy way to employ a refinement strategy that ensures uniformly spaced control points?


Thank you very much for your time. I am really grateful to be able to work with your code.



With best regards

Philipp Zilk

Institute for Mathematics and Computer-Based Simulation (IMCS)
University of the Bundeswehr Munich (UniBw M)
D-85577 Neubiberg / Germany

https://www.unibw.de/imcs-en

Dear Tom,
the best thing is to export your solution to Paraview, using sp_to_vtk.

Best,
Rafa

On 22.05.22 14:33, 🎶🎶🎶 via Geopdes-users wrote:
> Dear Rafael,
> When solving the three-dimensional Poisson equation, can GeoPDEs 3.0 be used 0 draw the image (4 dimensions) of solution U (x, y, z). I tried to operate it. The fourth dimension is embedded in the three-dimensional diagram. Is this reasonable？
> Best wish.
> Deeply grateful,
> Your Tom
>
>
>
>
>  
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users

Dear Rafael,
When solving the three-dimensional Poisson equation, can GeoPDEs 3.0 be used 0 draw the image (4 dimensions) of solution U (x, y, z). I tried to operate it. The fourth dimension is embedded in the three-dimensional diagram. Is this reasonable？
Best wish.
Deeply grateful,
Your Tom




 

Thank you Rafael，I'll think of other ways..Best wish to you.


 


?9?0?9?0?9?0
254...@qq...



 




------------------ 原始邮件 ------------------
发件人: "Rafael Vazquez"<va...@im...&gt;; 
发送时间: 2022年4月8日(星期五) 下午3:16
收件人: "🎶🎶🎶"<254...@qq...&gt;; "geopdes-users"<geo...@li...&gt;; 
主题: Re: [Geopdes-users] some questions about:GeoPDEs3.0



Dear Tom,
no, there is nothing ready in GeoPDEs for non-linear problems, except 
the example for Navier-Stokes equations.

Maybe some other users can share their experience. I have not 
implemented non-linear problems for a very long time.

Best,
Rafael

On 08.04.22 08:33, 🎶🎶🎶 via Geopdes-users wrote:
&gt; Dear Rafael,
&gt; &amp;nbsp; &amp;nbsp;How can I handle non-linear items according to the GeoPDEs3.0？Such as u^3 or u^2.Does geopdes have a ready-made toolkit.Best wishes to you!
&gt;
&gt;
&gt; Deeply grateful,
&gt; Your Tom
&gt;
&gt;
&gt;
&gt; &amp;nbsp;
&gt; _______________________________________________
&gt; Geopdes-users mailing list
&gt; Geo...@li...
&gt; https://lists.sourceforge.net/lists/listinfo/geopdes-users

Dear Tom,
no, there is nothing ready in GeoPDEs for non-linear problems, except 
the example for Navier-Stokes equations.

Maybe some other users can share their experience. I have not 
implemented non-linear problems for a very long time.

Best,
Rafael

On 08.04.22 08:33, 🎶🎶🎶 via Geopdes-users wrote:
> Dear Rafael,
>    How can I handle non-linear items according to the GeoPDEs3.0？Such as u^3 or u^2.Does geopdes have a ready-made toolkit.Best wishes to you!
>
>
> Deeply grateful,
> Your Tom
>
>
>
>  
> _______________________________________________
> Geopdes-users mailing list
> Geo...@li...
> https://lists.sourceforge.net/lists/listinfo/geopdes-users