You can subscribe to this list here.
2010 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(1) 
_{Nov}
(1) 
_{Dec}


2011 
_{Jan}

_{Feb}

_{Mar}
(1) 
_{Apr}

_{May}
(1) 
_{Jun}
(9) 
_{Jul}
(2) 
_{Aug}
(6) 
_{Sep}
(11) 
_{Oct}
(15) 
_{Nov}
(4) 
_{Dec}
(9) 
2012 
_{Jan}
(7) 
_{Feb}
(14) 
_{Mar}
(11) 
_{Apr}

_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2013 
_{Jan}
(8) 
_{Feb}

_{Mar}
(1) 
_{Apr}
(3) 
_{May}

_{Jun}

_{Jul}
(3) 
_{Aug}
(2) 
_{Sep}

_{Oct}

_{Nov}

_{Dec}
(4) 
2014 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}
(2) 
_{Jun}
(2) 
_{Jul}

_{Aug}

_{Sep}
(4) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 





1

2

3

4

5
(5) 
6

7

8
(1) 
9
(4) 
10

11

12

13

14

15

16

17

18
(1) 
19

20

21

22

23

24

25

26

27

28

29

30

31

From: Carlo de Falco <carlo.defalco@po...>  20120318 11:36:29

A new release of the nurbs package, labeled as version 1.3.6, has been uploaded to Source Forge The main changes from previous version include: * Various bug fixes, most notably a fix for a bug in "nrbexport" that was causing exported files to be randomly truncated * Improvement of the algorithm in "tbasisfun" to speed up computation of derivatives The package docs and download page is here: http://octave.sourceforge.net/nurbs/index.html Enjoy, Carlo 
From: Rafael Vazquez <vazquez@im...>  20120309 11:40:23

Dear Cyril, I agree with Carlo. The implementation for a surface in 3D should be very similar to what is already done for the boundary of the volumes. Take a look at the function sp_eval_boundary_side (also in the scalar case), and at the section 3 of the report, where we also give some explanations about the boundary. Regards, Rafa Il 09/03/2012 11:53, c. ha scritto: > On 9 Mar 2012, at 11:02, cyril cassisa wrote: > > >> Quadrature points are in 2d (u,v) >> msh class the variable geo_map and geo_map_der (jacobien) is 2x3. >> We have then to compute the determinant and inverse and also make a product of geo_map_der (jacobien) with space class variable shape_function_gradients which is of size 2 in domain (u,v). >> > I am not sure what exactly you mean, but please be aware that quadrature in geopdes is always done > in the physical space rather than in the reference space. > So what you need is to construct weights and nodes for a quadrature rule on your surface. > Quadrature on bivariate surfaces in 3d is already used to apply pressure boundary conditions in geopdes_elasticty, > to achieve this the method sp_eval_boundary_side from the class sp_vector_3d constructs quadrature nodes and weights > on the boundary of a 3d patch, you could use the code in there as inspiration. > > Hope this helps, > Carlo 
From: c. <carlo.defalco@gm...>  20120309 10:53:38

On 9 Mar 2012, at 11:02, cyril cassisa wrote: > Quadrature points are in 2d (u,v) > msh class the variable geo_map and geo_map_der (jacobien) is 2x3. > We have then to compute the determinant and inverse and also make a product of geo_map_der (jacobien) with space class variable shape_function_gradients which is of size 2 in domain (u,v). I am not sure what exactly you mean, but please be aware that quadrature in geopdes is always done in the physical space rather than in the reference space. So what you need is to construct weights and nodes for a quadrature rule on your surface. Quadrature on bivariate surfaces in 3d is already used to apply pressure boundary conditions in geopdes_elasticty, to achieve this the method sp_eval_boundary_side from the class sp_vector_3d constructs quadrature nodes and weights on the boundary of a 3d patch, you could use the code in there as inspiration. Hope this helps, Carlo 
From: cyril cassisa <ccassisa@gm...>  20120309 10:02:22

I incorporate the new BSpline function in the geoPDEs toolbox. Results are not so good for the moment because I made many approximation in the code. First, before looking more deeply in what is wrong in my implementation. I want to adapt the GeoPDEs toolbox to be able to treat problems on 3D surfaces. With only a parametrization in 2D U and V representing a surface in 3D in x,y,z. Today I got to the problem that the function *F *from (U,V) to (x,y,z) is now a 2x3 matrix. *Quadrature points* are in 2d (u,v) *msh *class the variable *geo_map *and *geo_map_der (jacobien) *is 2x3. We have then to compute the determinant and inverse and also make a product of *geo_map_der **(jacobien) ** *with *space *class variable *shape_function_gradients *which is of size 2 in domain (u,v). *What is the better solution to modify the code ?* I chose to modif the msh_2d and sp_nurbs_2d (bspline). To get a 3x3 matrix for *geo_map_der **(jacobien) **. *The 2 first lines represent the 2 tangent vectors. I add a 3rd line by computing the normal vector by vectorial product of the 2 tangent vectors. Then I got an inversible matrix, compute determinant and inverse. For the product with *shape_function_gradients *, I add a virtual line to compute it with the inversed 3x3 Jacobien matrix. Then I suppress the added line after computation. Results I obtain on the laplace equation examples, seem to be correct if the 3D surface is in the plan (Oxy) (i.e z constant). But the geomerty is in complete 3d, it seems to have some problem then. Hope my mail is clear enough. Don't hesitate to give me your advices. They are very helpful. I remember in previous email that you have already one people working on the extension on the 3d surface defining by 2d parametric domain. Is it possible to have his contact, to exchange with him directly ? Thank you very much. Cyril On Mon, Mar 5, 2012 at 10:43 PM, Rafael Vazquez <vazquez@...>wrote: > ** > Dear Cyril, > I reply below. > > Regards, > Rafa > > Il 05/03/2012 11:20, cyril cassisa ha scritto: > > Good morning, > > I come back to you to have your advises on changing the BSpline > function type in GeoPDEs. > I already correctly changed the geometry structure and mesh class. > I am now attaquing the last one, the space class. However it seems to be > the most important and the most complex to adapt. > > What I understand is that you precompute the basis function value for > the quadrature point on each direction in variables >  *shape_functions *and *shape_function_gradients *(depending to > what you need) > > In case of NURBS or BSpline the knot vector in U and V direction stay > the same over the domain and the quadrature points don't change parametric > coordinates. So it is easy to compute the basis functions and derivatives > on each direction in one time for all. > > In my case, Uknot is function of parametric coordinate v which change > the Uknot vector over the parametric domain. Basis functions changes, as > well as quadrature points parametric coordinates. > So, the first thing I understand is that I should change quite a lot the *space > *class to adapt it to a varying knot parametric domain. > *Do you think is the only way ?* > > Yes, I think so. Since your space of functions is different you will have > to create a different space class. > > > When you compute the *shape_functions *and *shape_function_gradients*, > you do not use the information of quadrature points parametric coordinates > contained in the msh class (*quad_nodes*), but you only use *nqn_dir *which > is sufficient if it is constant over the domain. > *Do you think I can use quad_nodes ?* > > Yes, and I think you should use them. Using *nqn_dir* is better for > tensor product spaces, but in your case using quad_nodes seems the best > choice. > > Then I can know the value of 'v' for the current quadrature point and > then compute the corresponding Uknot vector at this quadrature point, the > basis function and its derivatives. > > In space classes, for the other variables, I think it is OK and does not > need to be changed. Even if my parametric domain is varying, I still get > same number of element in U and V direction, same number of quadrature > points, same degrees of freedom and same indices of basis functions that do > not vanish in each element. > > So my work should focus on SP_NURBS_2D, SP_EVALUATE_COL_PARAM and > SP_BSPLINE_1D_PARAM, is it right ? > > Yes, I think so. Since *ndof*, *nsh* and *connectivity* are the same that > for Bsplines, you can keep that part, both in SP_BSPLINE_1D_PARAM and in > SP_EVALUATE_COL_PARAM. And since your space is not tensor product, I think > it doesn't make any sense to compute the *shape_functions* in the 1D > spaces. You will need to add the functions to compute them. > > As a first idea you could use something similar to *tbasisfun*, the > function that Carlo told you the other day. It computes a Bspline basis > function in a set of given points. In your case I think it would be more > efficient to compute several basis functions at a single point, but in any > case you need a function to compute them. The rest is simply reordering the > information in an array with the right size. > > And if you are planning to solve problems with nonhomogeneous boundary > conditions, probably you will need to change SP_EVAL_BOUNDARY_SIDE. Right > now the knot vector is the same for the opposite sides. > > > > Thank you very much for your time and your help. > It is of a great use, cause I become to be too much inside GeoPDEs codes > and afraid to mix things. > > Regards, > > Cyril Cassisa. > > > 
From: Rafael Vazquez <vazquez@im...>  20120309 10:00:01

Hi, I think that the best way to consider different materials (in any problem to be solved with GeoPDEs) is to use a multipatch geometry. The reason is that to obtain the right convergence, the discrete space must be just continuous on the interface between materials (tangentially continuous in Maxwell), and in GeoPDEs this is automatically done for the interface between patches. Higher continuity on the interface would give you unphysical oscillations in the solution, and a lower convergence rate. Moreover, defining the physical properties as a function of the patch (or of the subdomain) is much easier in multipatch. The way to do it is to define some functions for the physical properties (magnetic permeability and electric permittivity in Maxwell) that take the number of the patch as an argument. Then, when computing the matrices, you must use a function handle with a fixed number of patch. Something like this (in mp_solve_maxwell_eig_3d): for iptc = 1:npatch ... c_elec_patch = @(x, y, z) 1./c_elec_perm (x, y, z, iptc); [rs, cs, vs] = op_u_v_tp (sp{iptc}, sp{iptc}, msh{iptc}, c_elec_patch); ... end About the subdomains, they are not really used in GeoPDE. I added them in the multipatch geometry files for some examples I had in mind, but that I never finished. Using the subdomain instead of the patch number shouldn't be difficult to implement. And to create the geometry with the NURBS toolbox, you must do every patch separately, and then put all together in one single file (see geo_specs_mp_v07.txt), taking care of the interfaces. If you want to use the nurbs toolbox, the functions are described here: http://octave.sourceforge.net/nurbs/overview.html For simple geometries you will only use a small bunch of them (line, circ, ruled, extrude, revolve, tform...) Regards, Rafa Il 08/03/2012 15:15, wn0@... ha scritto: > Dear Geopde users, > > I am currently working on FEM for electromagnetic problems and > trying to using Geopde to simulate resonante cavity geometries as in > classical FEM.For simple geometries it ok but I have some questions as > following: > > 1). Does Geopde support inhomogeneous geometry?( rectangular cavity > loaded with dielectric) and if so on how to build geometry by NURBS > toolbox? > > 2)In multipatch package , they can be set as heterogeneous objects > for each domain? > > I am sorry if my questions so stupid. I am trying to look inside > deepper in Geopde. > > Thank you, > > > >  > This message was sent using IMP, the Internet Messaging Program. > > > >  > Virtualization& Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization  but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: <wn0@al...>  20120308 14:33:57

Dear Geopde users, I am currently working on FEM for electromagnetic problems and trying to using Geopde to simulate resonante cavity geometries as in classical FEM.For simple geometries it ok but I have some questions as following: 1). Does Geopde support inhomogeneous geometry?( rectangular cavity loaded with dielectric) and if so on how to build geometry by NURBS toolbox? 2)In multipatch package , they can be set as heterogeneous objects for each domain? I am sorry if my questions so stupid. I am trying to look inside deepper in Geopde. Thank you,  This message was sent using IMP, the Internet Messaging Program. 
From: c. <carlo.defalco@gm...>  20120305 17:19:03

On 5 Mar 2012, at 16:50, Rafael Vazquez wrote: > Dear Adriano, > I didn't check the values, but maybe the error is because in the nurbs > toolbox the coefficients are the weighted control points, that is, the > control points multiplied by the weight. Anyway, Dominik did the same > geometry this last September, using the functions in the nurbs toolbox. > Below I copy what he did. If you want, you can save the geometry as a > text file using nrbexport. If you intend to use nrbexport, please beware that there is a small bug in the version contained in the currently released nurbs toolbox (v1.3.5) the bug has already been fixed and the corrected function will be in the next release (v1.3.6). For the moment you can download the correct version of nrbexport.m from this link: <http://octave.svn.sourceforge.net/viewvc/octave/trunk/octaveforge/extra/nurbs/inst/nrbexport.m?revision=9622&contenttype=text%2Fplain>; > Regards, > Rafa c. 
From: Rafael Vazquez <vazquez@im...>  20120305 15:50:38

Dear Adriano, I didn't check the values, but maybe the error is because in the nurbs toolbox the coefficients are the weighted control points, that is, the control points multiplied by the weight. Anyway, Dominik did the same geometry this last September, using the functions in the nurbs toolbox. Below I copy what he did. If you want, you can save the geometry as a text file using nrbexport. Regards, Rafa # useful constants w = sqrt(2) /2; h = 1; wh = w*h; # assembling the circle pnts = zeros(4,3,3); pnts(:,:,1) = [ 1.0 w 0.0; 0.0 w 1.0; h wh h ; 1.0 w 1.0]; pnts(:,:,2) = [ w 0.0 w; w 0.0 w; wh h wh ; w 1.0 w]; pnts(:,:,3) = [ 0.0 w 1.0; 1.0 w 0.0; h wh h ; 1.0 w 1.0]; # knot vectors knots{1} = [0 0 0 1 1 1]; knots{2} = [0 0 0 1 1 1]; circle = nrbmak(pnts,knots); geometry = geo_load (circle); 
From: Rafael Vazquez <vazquez@im...>  20120305 14:43:44

Dear Cyril, I reply below. Regards, Rafa Il 05/03/2012 11:20, cyril cassisa ha scritto: > Good morning, > > I come back to you to have your advises on changing the BSpline > function type in GeoPDEs. > I already correctly changed the geometry structure and mesh class. > I am now attaquing the last one, the space class. However it seems to > be the most important and the most complex to adapt. > > What I understand is that you precompute the basis function value for > the quadrature point on each direction in variables >  /shape_functions /and /shape_function_gradients /(depending to what > you need) > > In case of NURBS or BSpline the knot vector in U and V direction stay > the same over the domain and the quadrature points don't change > parametric coordinates. So it is easy to compute the basis functions > and derivatives on each direction in one time for all. > > In my case, Uknot is function of parametric coordinate v which change > the Uknot vector over the parametric domain. Basis functions changes, > as well as quadrature points parametric coordinates. > So, the first thing I understand is that I should change quite a lot > the /space /class to adapt it to a varying knot parametric domain. > *Do you think is the only way ?* Yes, I think so. Since your space of functions is different you will have to create a different space class. > > When you compute the /shape_functions /and /shape_function_gradients/, > you do not use the information of quadrature points parametric > coordinates contained in the msh class (/quad_nodes/), but you only > use /nqn_dir /which is sufficient if it is constant over the domain. > *Do you think I can use quad_nodes ?* Yes, and I think you should use them. Using /nqn_dir/ is better for tensor product spaces, but in your case using quad_nodes seems the best choice. > Then I can know the value of 'v' for the current quadrature point and > then compute the corresponding Uknot vector at this quadrature point, > the basis function and its derivatives. > > In space classes, for the other variables, I think it is OK and does > not need to be changed. Even if my parametric domain is varying, I > still get same number of element in U and V direction, same number of > quadrature points, same degrees of freedom and same indices of basis > functions that do not vanish in each element. > > So my work should focus on SP_NURBS_2D, SP_EVALUATE_COL_PARAM and > SP_BSPLINE_1D_PARAM, is it right ? Yes, I think so. Since /ndof/, /nsh/ and /connectivity/ are the same that for Bsplines, you can keep that part, both in SP_BSPLINE_1D_PARAM and in SP_EVALUATE_COL_PARAM. And since your space is not tensor product, I think it doesn't make any sense to compute the /shape_functions/ in the 1D spaces. You will need to add the functions to compute them. As a first idea you could use something similar to /tbasisfun/, the function that Carlo told you the other day. It computes a Bspline basis function in a set of given points. In your case I think it would be more efficient to compute several basis functions at a single point, but in any case you need a function to compute them. The rest is simply reordering the information in an array with the right size. And if you are planning to solve problems with nonhomogeneous boundary conditions, probably you will need to change SP_EVAL_BOUNDARY_SIDE. Right now the knot vector is the same for the opposite sides. > > Thank you very much for your time and your help. > It is of a great use, cause I become to be too much inside GeoPDEs > codes and afraid to mix things. > > Regards, > > Cyril Cassisa. > 
From: Adriano Côrtes <adrimacortes@gm...>  20120305 14:32:30

Dear Geopdes developers, First of all I'd like to congratulate you on the good job that you did. Geopdes toolbox is really nice and an excellent tool. After some time trying to figure out what was happening I decided to write. I adapted ex_article_15line.m to work with the homogeneous Dirichlet problem  \laplacian u + u = 1 on \Omega where closure(\Omega) is the unitary disk parameterized as a 2d NURBS region. I parameterized the disk with "geo_disk.txt" 2 1 2 2 3 3 0.00000 0.00000 0.00000 1.00000 1.00000 1.00000 0.00000 0.00000 0.00000 1.00000 1.00000 1.00000 0.70710678118655 1.4142135623731 0.70710678118655 0.00000 0.00000 0.0000 0.70710678118655 1.4142135623731 0.70710678118655 0.70710678118655 0.00000 0.70710678118655 1.4142135623731 0.00000 1.4142135623731 0.70710678118655 0.00000 0.70710678118655 1.00000 0.70710678118655 1.00000 0.70710678118655 0.50000 0.70710678118655 1.00000 0.70710678118655 1.00000 This parametrization in the one that the elements (when refined, cause the one above we have only one element) look like a curved chessboard (the data above I generated based on E. Cohen et al.  "Analysisaware modeling: Understanding quality considerations in modeling for isogeometric analysis"). I'm really confident that the data above is correct, but when I run the script the output geometry (visualized in Paraview) is not of a disk, but instead a deformed disk with the x and y axis scaled. My guess is that somewhere the NURBS weights are not being used correctly, but it's really just a guess, that why I'm needing your help. Thanks in advance. Adriano Côrtes.  Adriano Côrtes ================================================= Graduate student at High Performance Computing Center (NACAD) Federal University of Rio de Janeiro (UFRJ) Rio de Janeiro, Brazil 
From: cyril cassisa <ccassisa@gm...>  20120305 10:20:13

Good morning, I come back to you to have your advises on changing the BSpline function type in GeoPDEs. I already correctly changed the geometry structure and mesh class. I am now attaquing the last one, the space class. However it seems to be the most important and the most complex to adapt. What I understand is that you precompute the basis function value for the quadrature point on each direction in variables  *shape_functions *and *shape_function_gradients *(depending to what you need) In case of NURBS or BSpline the knot vector in U and V direction stay the same over the domain and the quadrature points don't change parametric coordinates. So it is easy to compute the basis functions and derivatives on each direction in one time for all. In my case, Uknot is function of parametric coordinate v which change the Uknot vector over the parametric domain. Basis functions changes, as well as quadrature points parametric coordinates. So, the first thing I understand is that I should change quite a lot the *space *class to adapt it to a varying knot parametric domain. *Do you think is the only way ?* When you compute the *shape_functions *and *shape_function_gradients*, you do not use the information of quadrature points parametric coordinates contained in the msh class (*quad_nodes*), but you only use *nqn_dir *which is sufficient if it is constant over the domain. *Do you think I can use quad_nodes ?* Then I can know the value of 'v' for the current quadrature point and then compute the corresponding Uknot vector at this quadrature point, the basis function and its derivatives. In space classes, for the other variables, I think it is OK and does not need to be changed. Even if my parametric domain is varying, I still get same number of element in U and V direction, same number of quadrature points, same degrees of freedom and same indices of basis functions that do not vanish in each element. So my work should focus on SP_NURBS_2D, SP_EVALUATE_COL_PARAM and SP_BSPLINE_1D_PARAM, is it right ? Thank you very much for your time and your help. It is of a great use, cause I become to be too much inside GeoPDEs codes and afraid to mix things. Regards, Cyril Cassisa. On Wed, Feb 22, 2012 at 2:04 AM, Rafael Vazquez <vazquez@...>wrote: > Il 21/02/2012 14:43, c. ha scritto: > > On 21 Feb 2012, at 15:00, cyril cassisa wrote: > > > > > > > >> *Do you think that I am going on a big complex mess ? or do you think it > >> will be only simple modifications ?* > >> > > I think it shouldn't be a big problem if you just skip all the > tensorproduct based classes and their > > specific methods (those with neame ending in _tp). > > > > > Yes, I agree that it is better to start without the _tp functions. Maybe > in a second step you can use some of the ideas there, but I don't > recommend to use them for now. > > Rafa > > >  > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL  plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnowd2d > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > Rafael Vazquez vazquez@... via<http://support.google.com/mail/bin/answer.py?hl=en&ctx=mail&answer=1311182>; lists.sourceforge.net Feb 22 (13 days ago) to geopdesusers Dear Cyril, from your explanation I understand that you have defined the structure, but not the functions to work with it. The most important thing is to write the functions to evaluate the basis functions (and derivatives) at some points, and to evaluate the parametrization (and derivatives) of your domain. Kind of a RCKBS toolbox. Once you have this toolbox, computing the space shouldn't give you any trouble. And as you said, you also have to change the quadrature rule. For this you must decide which are the quadrature points in the curved elements of the parametric domain, and give a function to compute them, but the fields of the msh structure should remain basically the same. Regards, Rafa Il 21/02/2012 10:30, cyril cassisa ha scritto: > Hi everyone, > > I am working on other BSpline functions called Regular CurvedKnot > BSpline (RCKBS). > These functions are interesting for representing particular geometries > (surfaces and volumes) for example it can deal with continuity variation > over the domain. > The parametric domain is then not a regular grid as for BSpline and Nurbs. > > I am trying to incorporate RCKBS in GeoPDEs toolbox. But I encounter some > difficulties. > For that I create a new structure RCKBS using the same style as NURBS > structure. > Then I see that I also have to modify the mesh stucture. > Because in the case of RCKBS, the knot vector varies over the parametric > domain. For example for a surface: >  Uknot(v): Uknot is function of the v direction >  Vknot(u): Vknot is function of the u direction > Then I have a lowerbound and upperbound knot vectors for U and for V. > > I think that then, I will have to modify the quadratic rule computation as > my parametric domain is not regular on u and v direction, modify the msh > and space as well. > *Do you think that I am going on a big complex mess ? or do you think it > will be only simple modifications ?* > > I have also another question about the GeoPDEs toolbox. > For surfaces you consider that we are necessarily in 2D and volume is for > 3D. > *Why does GeoPDEs cannot deal with 3D surfaces meaning that the physical > points are in 3d space but knots are only on U and V directions ?* > I try to consider my 3D surface as a volume with no depth but I got some > bugs then from boundary condition problem (I think). > > Thank you very much for your help. > Thanks to GeoPDEs developpers. It is very nice to have access to an open > source IGA toolbox. > Hope I will be able to bring my contribution on it. > > Sincerely > > Cyril Cassisa. > PostDoc INRIA > 