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}
(5) 
_{Oct}
(3) 
_{Nov}
(1) 
_{Dec}
(4) 
2015 
_{Jan}
(5) 
_{Feb}
(10) 
_{Mar}
(12) 
_{Apr}
(14) 
_{May}
(26) 
_{Jun}
(7) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

From: Rafael Vazquez <vazquez@im...>  20150617 16:18:33

Hi Giulia, found it. You also need to update the nurbs toolbox to the current version in the repository (version 1.3.10 will be released soon). You can get it here: http://sourceforge.net/p/octave/code/HEAD/tree/trunk/octaveforge/extra/nurbs/ Sorry about that, Rafa 
From: Rafael Vazquez <vazquez@im...>  20150617 15:57:16

Hi Giulia, I am not able to reproduce the error. Have you tried to update the repository (svn up) recently? Rafa 
From: Giulia <giulia.martini@gm...>  20150617 15:30:39

Hi Rafael, sorry to bother you again, I'm still struggling to run the beta version of GeoPDEs. I am using Matlab R2012a and version 1.3.9 of the nurbs toolbox. Some of the examples run ok, but the ones in the following list don't. ex_advection_diffusion_square ex_article_section_514 ex_laplace_1d ex_laplace_beltrami ex_laplace_iso_plate ex_laplace_iso_ring ex_laplace_iso_ring_mixed_bc ex_laplace_plate ex_laplace_ring ex_laplace_ring_mixed_bc ex_laplace_square I am attaching a screenshot of the error stack trace of ex_laplace_beltrami.m. The other errors are similar, and they all have these lines in common: Undefined function 'max' for input arguments of type 'cell'. > Error in findspan (line 36) if (max(u(:))>U(end)  min(u(:))<U(1)) > Error in bspeval (line 54) > s = findspan(nc1, d, u(:), k); % s = findspan(nc1, d, > u[col], k); > Error in nrbeval (line 252) > val = bspeval(nurbs.order1,nurbs.coefs,nurbs.knots,tt(:)'); > Error in geo_nurbs (line 65) > F = nrbeval (nurbs, pts); > Error in geo_load>@(PTS)geo_nurbs(bnd(ibnd),deriv,deriv2,PTS,0,rdim) (line > 105) > geometry.boundary(ibnd).map = @(PTS) geo_nurbs (bnd(ibnd), > deriv, deriv2, > PTS, 0, rdim); Do you have any idea of what I might be doing wrong? Thank you, Giulia On Thu, Jun 11, 2015 at 11:09 AM, Rafael Vázquez <vazquez@...> wrote: > Hi Giulia, > it may be a problem of the version of the NURBS toolbox. In my computer it > is working both in Octave and Matlab, with version 1.3.9 of the toolbox. > > Rafa > > > Hi Rafael, > > > > Thank you for the answers. > > I downloaded the manifolds branch at this address: > > http://sourceforge.net/p/geopdes/code/HEAD/tree/branches/manifolds/ > > > > But if I run the "LaplaceBeltrami problem on a 3D surface" example, I > get > > the error "Undefined function 'max' for input arguments of type 'cell'." > > in > > findspan() called inside sp_drchlt_l2_proj(). > > > > Is this normal because I am using a beta version, or should it work? > > > > Thank you, > > > > Giulia > > > > On Mon, Apr 27, 2015 at 10:56 AM, Rafael Vazquez <vazquez@...> > > wrote: > > > >> Hi Giulia, > >> > >> On 24/04/2015 20:31, Giulia wrote: > >> > >>> Hi everyone, > >>> > >>> is there any reference or documentation on how GeoPDEs multipatch > >>> works? > >>> > >> There is no special documentation for multipatch problems, only what is > >> written in the technical report. Basically, we assume that the patches > >> match conformingly, that is, on the interface they have the same knot > >> vector (up to an affine transformation) and they share the same control > >> points. With that, the functions are easily glued together with C^0 > >> continuity, since one function from one patch corresponds to another > >> function in the other patch. You can generate the information to deal > >> with > >> multipatch geometries using the function nrbmultipatch from the nurbs > >> toolbox. > >> > >>> > >>> Is it possible to control the regularity of the solution between > >>> different > >>> patches and along the interfaces? > >>> > >> In geopdes we have only implemented the C^0 case, for higher regularity > >> you will have to implement that yourself. Notice that you will need the > >> derivatives on the boundary, which is not contained in the boundary > >> structures as they are now. To get the derivatives on the boundary you > >> can > >> use the same approach that we have already used to impose the boundary > >> conditions in a weak form, in the function sp_weak_drchlt_bc of the > >> geopdes_fluid package. > >> > >> > >>> In a previous thread I read that someone made GeoPDEs work with 3D > >>> surfaces. Do you know if and where I can find an example of that? > >>> > >> Actually, I am preparing a new version of geopdes that works with 3D > >> surfaces. You can already download it from our sourceforge repository > >> (packages base, elasticity and multipatch), but be aware that it is > >> still a > >> beta version. Otherwise, you can try to contact the users that have > >> already > >> implemented 3D surfaces in the current version. > >> > >> I hope this helps, > >> Rafa > >> > > >  > > _______________________________________________ > > Geopdesusers mailing list > > Geopdesusers@... > > https://lists.sourceforge.net/lists/listinfo/geopdesusers > > > > 
From: Rafael Vazquez <vazquez@im...>  20150615 16:39:03

Dear Yuvraj Singh, I think the problem is that, when you call msh_2d, you must set to true the computation of the second derivative: msh = msh_2d (zeta, qn, qw, geometry,'der2', true); Regards, Rafa On 15/06/2015 13:42, Yuvraj Singh wrote: > I tried to use the function 'sp_evaluate_col.m' > (GeoPDEs\geopdes_base\inst\space\@sp_bspline_2d) to calculate > 'shape_function_hessians' i.e. hessian of the shape functions. > It was giving the error that the field 'shape_function_hessians' doesn't > exist. > > Then I read in 'msh_2d.m '(GeoPDEs\geopdes_base\inst\msh\@msh_2d) that you > have not provided the second order derivatives of the shape functions. > > Is there any way i can calculate the second order derivatives. > Or if you can provide us ,Please help us. >  > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers 
From: Yuvraj Singh <yuvrajsingh90014@gm...>  20150615 11:42:20

I tried to use the function 'sp_evaluate_col.m' (GeoPDEs\geopdes_base\inst\space\@sp_bspline_2d) to calculate 'shape_function_hessians' i.e. hessian of the shape functions. It was giving the error that the field 'shape_function_hessians' doesn't exist. Then I read in 'msh_2d.m '(GeoPDEs\geopdes_base\inst\msh\@msh_2d) that you have not provided the second order derivatives of the shape functions. Is there any way i can calculate the second order derivatives. Or if you can provide us ,Please help us. 
From: Rafael Vázquez <vazquez@im...>  20150611 09:09:15

Hi Giulia, it may be a problem of the version of the NURBS toolbox. In my computer it is working both in Octave and Matlab, with version 1.3.9 of the toolbox. Rafa > Hi Rafael, > > Thank you for the answers. > I downloaded the manifolds branch at this address: > http://sourceforge.net/p/geopdes/code/HEAD/tree/branches/manifolds/ > > But if I run the "LaplaceBeltrami problem on a 3D surface" example, I get > the error "Undefined function 'max' for input arguments of type 'cell'." > in > findspan() called inside sp_drchlt_l2_proj(). > > Is this normal because I am using a beta version, or should it work? > > Thank you, > > Giulia > > On Mon, Apr 27, 2015 at 10:56 AM, Rafael Vazquez <vazquez@...> > wrote: > >> Hi Giulia, >> >> On 24/04/2015 20:31, Giulia wrote: >> >>> Hi everyone, >>> >>> is there any reference or documentation on how GeoPDEs multipatch >>> works? >>> >> There is no special documentation for multipatch problems, only what is >> written in the technical report. Basically, we assume that the patches >> match conformingly, that is, on the interface they have the same knot >> vector (up to an affine transformation) and they share the same control >> points. With that, the functions are easily glued together with C^0 >> continuity, since one function from one patch corresponds to another >> function in the other patch. You can generate the information to deal >> with >> multipatch geometries using the function nrbmultipatch from the nurbs >> toolbox. >> >>> >>> Is it possible to control the regularity of the solution between >>> different >>> patches and along the interfaces? >>> >> In geopdes we have only implemented the C^0 case, for higher regularity >> you will have to implement that yourself. Notice that you will need the >> derivatives on the boundary, which is not contained in the boundary >> structures as they are now. To get the derivatives on the boundary you >> can >> use the same approach that we have already used to impose the boundary >> conditions in a weak form, in the function sp_weak_drchlt_bc of the >> geopdes_fluid package. >> >> >>> In a previous thread I read that someone made GeoPDEs work with 3D >>> surfaces. Do you know if and where I can find an example of that? >>> >> Actually, I am preparing a new version of geopdes that works with 3D >> surfaces. You can already download it from our sourceforge repository >> (packages base, elasticity and multipatch), but be aware that it is >> still a >> beta version. Otherwise, you can try to contact the users that have >> already >> implemented 3D surfaces in the current version. >> >> I hope this helps, >> Rafa >> >  > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers > 
From: Giulia <giulia.martini@gm...>  20150610 18:14:24

Hi Rafael, Thank you for the answers. I downloaded the manifolds branch at this address: http://sourceforge.net/p/geopdes/code/HEAD/tree/branches/manifolds/ But if I run the "LaplaceBeltrami problem on a 3D surface" example, I get the error "Undefined function 'max' for input arguments of type 'cell'." in findspan() called inside sp_drchlt_l2_proj(). Is this normal because I am using a beta version, or should it work? Thank you, Giulia On Mon, Apr 27, 2015 at 10:56 AM, Rafael Vazquez <vazquez@...> wrote: > Hi Giulia, > > On 24/04/2015 20:31, Giulia wrote: > >> Hi everyone, >> >> is there any reference or documentation on how GeoPDEs multipatch works? >> > There is no special documentation for multipatch problems, only what is > written in the technical report. Basically, we assume that the patches > match conformingly, that is, on the interface they have the same knot > vector (up to an affine transformation) and they share the same control > points. With that, the functions are easily glued together with C^0 > continuity, since one function from one patch corresponds to another > function in the other patch. You can generate the information to deal with > multipatch geometries using the function nrbmultipatch from the nurbs > toolbox. > >> >> Is it possible to control the regularity of the solution between different >> patches and along the interfaces? >> > In geopdes we have only implemented the C^0 case, for higher regularity > you will have to implement that yourself. Notice that you will need the > derivatives on the boundary, which is not contained in the boundary > structures as they are now. To get the derivatives on the boundary you can > use the same approach that we have already used to impose the boundary > conditions in a weak form, in the function sp_weak_drchlt_bc of the > geopdes_fluid package. > > >> In a previous thread I read that someone made GeoPDEs work with 3D >> surfaces. Do you know if and where I can find an example of that? >> > Actually, I am preparing a new version of geopdes that works with 3D > surfaces. You can already download it from our sourceforge repository > (packages base, elasticity and multipatch), but be aware that it is still a > beta version. Otherwise, you can try to contact the users that have already > implemented 3D surfaces in the current version. > > I hope this helps, > Rafa > 
From: Rafael Vazquez <vazquez@im...>  20150522 08:08:20

Dear Rahul Yadav, as you said, in GeoPDEs we only provide uniform refinement in the parametric domain. I have never tried to implement anything to improve the refinement in the physical domain. Actually, I do not remember any paper that continues the research in that direction. Regards, Rafa On 22/05/2015 07:53, rahul yadav wrote: > Dear Sir, > > Thanks for the kind reply. I think, I haven't made my question clear > and I apologize for that. > > I want to ask about the uniform meshing in the physical space. > Actually, I am doing the uniform meshing in parametric space but when > I am plotting it in the physical space, it is not uniform. The same > problem has been reported in the first of paper of Isogeometric by > Hughes /et.al <http://et.al>/ [2005] and they have suggested some > improvements in the appendix of that paper. It will be very kind if > you can tell me if there is similar kind of improvements present in > the Geopde. > > I hope to hear from you soon. > > > with best regards, > > Rahul Yadav > 
From: Rafael Vazquez <vazquez@im...>  20150521 12:58:28

Dear Naveed, when you call sp_precompute you are basically computing all the information of the space, that is, for all the elements you compute all the nonvanishing basis functions for every quadrature point. This consumes a lot of memory, especially in the 3D case. Things get worse when you increase the degree. In your particular case for the Greville points, since you are taking the whole domain as one single element, it will get worse whenever you increase the number of degrees of freedom, for instance, if you reduce the regularity. To avoid these memory problems we introduced classes in version 2 of GeoPDEs. The "precompute" functions are left there mostly for didactic purposes, but should not be used in general. Since you are going to use the Greville points to impose the boundary conditions, you can probably use sp_eval_boundary_side, instead of sp_precompute. This should allow you to avoid the problem. Regards, Rafa 
From: Rafael Vazquez <vazquez@im...>  20150521 12:43:42

Dear Rahul Yadav, the function nrbkntplot only plots the geometry with the knot vector, it does not generate any mesh. In all the examples in GeoPDEs, the variable nsub automatically creates a uniform refinement, assuming that the starting mesh is also uniform. Regards, Rafa On 07/05/2015 16:16, rahul yadav wrote: > Hi, > > I am trying to do the analysis of infinite plate with circular hole. I am > trying to mesh it using the function nrbkntplot, but the mesh is not > uniform. It will be very kind if you can help me in making a uniform mesh > of the geometry. > > Thank You > > Rahul Yadav >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers 
From: naveed ahmed <n_ahmed81@ya...>  20150521 11:34:02

Dear Rafael, I have read some of the discussion between you Pavel and Marti and try to implement the idea of the essential boundary in 3D and found some memory issue. The code considers the similar structure as for the 2D case. After creating mesh msh_temp=msh_3d({[0 1], [0 1], [0 1]}, gravpts, {[], [], []}, ... geometry, 'boundary', true, 'der2', false); clear gravpts; msh_temp = msh_precompute (msh_temp); sp_tmp = sp_nurbs_3d (geometry.nurbs, msh_temp); sp_tmp = sp_precompute (sp_tmp, msh_temp); The following error occur's >> Out of memory. Type HELP MEMORY for your options. Error in sp_nurbs_3d/sp_precompute_param (line 156) sp.shape_function_gradients(1,:,:,:) = (Bu  shape_functions .* Du)./D; Another question related to the operator "op_vel_dot_gradu_v_tp", if i am not wrong one can also use this function for the terms occurring in 3D? Actully, I wanted to use or a modification of the function for Saddle point problem. Thank you best regardsnaveed PS: I don't know why i can email to geo_pdes list. On Friday, 24 April 2015, 17:29, naveed ahmed <n_ahmed81@...> wrote:  Dear Rafael, Thanks for the details reply. I will try to implement if or not succeded, will ask you again. Best  From: Rafael Vazquez <vazquez@...>; To: naveed ahmed <n_ahmed81@...>; Cc: <geopdesusers@...>; Subject: Re: GeoPdes help Sent: Fri, Apr 24, 2015 3:14:55 PM  Dear Naveed, for the first part of your message (separating Neumann and Dirichlet conditions), as you may have seen GeoPDEs always works with complete boundary sides. The easiest way to solve this is to create your cube as a multipatch geometry, separating different conditions into different patches, but this would reduce the continuity between patches. Another possibility, but more difficult to implement, is that you create some functions adhoc, in such a way that to impose the Neumann and Dirichlet boundary conditions you only compute the integrals in a given list of boundary elements. For instance, for Neumann conditions you should first decide the elements of the boundary on which you want to compute the integrals, and then call op_f_v_list (sp_side, msh_side, gval, element_list) This function should do the loop only in the elements of the list. Since the mesh is Cartesian it should not be difficult to compute this list of elements, using the function sub2ind. You should do a similar thing for Dirichlet conditions. For the second part of your message, you can implement the boundary function without any loop, using the logical operators in a smart way. For instance, for your condition it should work something like this: value = sin(2*pi) * ((y>=5.0/8.0eps) & (y<=0.75+eps) & (z>= 5.0/8.0eps) & (z<= 0.75 +eps)); Something similar is done in the example of the laplacian in the plate. Notice that I have used the operator & (vectorial) and not && (scalar). I have also removed the condition x==0, since I would check that using the number of the side. I hope this helps, Rafa On 24/04/2015 13:03, naveed ahmed wrote: Dear Rafael, I need some suggestions regarding the inflow boundary conditions and boundary values in cube. What I want to have is as follows: if ((fabs(x1) < eps) && ( y>=3.0/8.0eps) && (y<=0.5+eps) && (z>=0.5eps) && (z<=5.0/8.0+eps)) { cond = NEUMANN; } else cond = DIRICHLET; and then the corresponding boundary values are (eps =1e06) if ((x==0) && (y>=5.0/8.0eps) && (y<=0.75+eps) && (z>= 5.0/8.0eps) && (z<= 0.75 +eps)) { value = sin(2*pi); } else value = 0.0; What I am trying in the function where i define my boundary conditions or boundary values is as follows { value=zeros(size(x)); dir=size(x) for i=1:dir(1) for j=1:dir(2) if (x(i,j) == 0 && y(i,j)>5./8. ....... (the similar if statement above) value(i,j) = sin (2*pi); end end } Could you please help me in this regard as you have the knowledge. Best wishes Naveed  
From: Rafael Vazquez <vazquez@im...>  20150519 12:29:29

Dear Eli, when you plot in Paraview, using sp_to_vtk, you plot the correct results. You don't get the maximum and minimum values of the solution vector because the basis functions are not interpolatory, and less or equal to one. Rafa On 19/05/2015 13:13, John Eli wrote: > Dear Rafa, > > Thanks for your nice guidance for the GeoPDEs. Could you please tell > me the best way of plotting and interpreting the results (important is > the interpretation then). If I compute the errors, i can see the > results which are correct. On the other hand if i plot using > sp_to_vtk(), the results are different then expected. As I also wrote > you in one of my email that the maximum and minimum of the solution > vector is not the similar or nearby which shows in the vtk plots. > > best wishes > Eli > > > >  > Date: Wed, 13 May 2015 11:58:33 +0200 > From: vazquez@... > To: john.eli90@...; geopdesusers@... > Subject: Re: [Geopdesusers] problem in an operator > > Dear Eli, > for 2D examples, and in the case you use the isoparametric approach > (NURBS geometry, NURBS functions), you can create a NURBS geometry > with the third coefficient equal to the solution: > nurbs = geometry.nurbs; > nurbs.coefs(3,:,:) = reshape (u, [1, nurbs.number]) .* nurbs.coefs(4,:,:); > > I multiply by the weight because the NURBS toolboxx works with > homogeneous coordinates. Then you can plot it with nrbctrlplot or > nrbkntplot. > > Rafa > > On 13/05/2015 11:38, John Eli wrote: > > Dear Rafa, > > Thanks for the explanation. Yes, that's everything is fine what > you said. But is there a way to really compare what have been > shown in figure using paraview and the minimum and maximum > obtained from the solution vector itself? > > Best > Eli > >  > Date: Wed, 13 May 2015 09:23:44 +0200 > From: vazquez@... <mailto:vazquez@...> > To: john.eli90@... <mailto:john.eli90@...>; > geopdesusers@... > <mailto:geopdesusers@...> > Subject: Re: [Geopdesusers] problem in an operator > > Dear Eli, > that's not surprising, since Bsplines (and NURBS) basis functions > are not interpolatory, and their values are between 0 and 1. This > difference between the solution vector (the control variables) and > the plotted solution is analogous to the difference between the > control points and the real geometry. > > In any case, for Paraview we are evaluating the solution exactly > at a given set of points. If you use enough points, you will get > an accurate plot of the computed solution. > > Rafa > > 
From: Rafael Vazquez <vazquez@im...>  20150515 10:28:24

Dear Eli, if you already know the position in the parametric domain, you can compute the value of the solution with sp_eval, it will automatically find the cell using findspan. If you only know the position in the physical domain you can compute the pullback to the parametric domain by solving a nonlinear problem. There was a discussion with Pavel about this some months ago, check the archives. Regards, Rafa On 15/05/2015 12:03, John Eli wrote: > Actually I want to compute some values at the some point and for that > i have to find some particular points on each cell and if the points > lies within that cell, i have to compute the basis function > corresponding to that point and multiply by the vector. In > mathematical sense u_h(x_p,y_p). > > best > eli > >  > Date: Fri, 15 May 2015 11:59:05 +0200 > From: vazquez@... > To: john.eli90@...; geopdesusers@... > Subject: Re: points in cell > > Dear Eli, > I am not sure to understand what you want. Can you be more precise? > > Rafa > > On 15/05/2015 11:48, John Eli wrote: > > Dear Rafa, > > Could you please guide me how to get cells and find some > particular points on that? > > best regards > Eli > > 
From: John Eli <john.eli90@ho...>  20150515 10:03:40

Actually I want to compute some values at the some point and for that i have to find some particular points on each cell and if the points lies within that cell, i have to compute the basis function corresponding to that point and multiply by the vector. In mathematical sense u_h(x_p,y_p). best eli Date: Fri, 15 May 2015 11:59:05 +0200 From: vazquez@... To: john.eli90@...; geopdesusers@... Subject: Re: points in cell Dear Eli, I am not sure to understand what you want. Can you be more precise? Rafa On 15/05/2015 11:48, John Eli wrote: Dear Rafa, Could you please guide me how to get cells and find some particular points on that? best regards Eli 
From: Rafael Vazquez <vazquez@im...>  20150515 09:59:14

Dear Eli, I am not sure to understand what you want. Can you be more precise? Rafa On 15/05/2015 11:48, John Eli wrote: > Dear Rafa, > > Could you please guide me how to get cells and find some particular > points on that? > > best regards > Eli 
From: John Eli <john.eli90@ho...>  20150515 09:48:57

Dear Rafa, Could you please guide me how to get cells and find some particular points on that? best regards Eli 
From: Rafael Vazquez <vazquez@im...>  20150513 09:58:42

Dear Eli, for 2D examples, and in the case you use the isoparametric approach (NURBS geometry, NURBS functions), you can create a NURBS geometry with the third coefficient equal to the solution: nurbs = geometry.nurbs; nurbs.coefs(3,:,:) = reshape (u, [1, nurbs.number]) .* nurbs.coefs(4,:,:); I multiply by the weight because the NURBS toolboxx works with homogeneous coordinates. Then you can plot it with nrbctrlplot or nrbkntplot. Rafa On 13/05/2015 11:38, John Eli wrote: > Dear Rafa, > > Thanks for the explanation. Yes, that's everything is fine what you > said. But is there a way to really compare what have been shown in > figure using paraview and the minimum and maximum obtained from the > solution vector itself? > > Best > Eli > >  > Date: Wed, 13 May 2015 09:23:44 +0200 > From: vazquez@... > To: john.eli90@...; geopdesusers@... > Subject: Re: [Geopdesusers] problem in an operator > > Dear Eli, > that's not surprising, since Bsplines (and NURBS) basis functions are > not interpolatory, and their values are between 0 and 1. This > difference between the solution vector (the control variables) and the > plotted solution is analogous to the difference between the control > points and the real geometry. > > In any case, for Paraview we are evaluating the solution exactly at a > given set of points. If you use enough points, you will get an > accurate plot of the computed solution. > > Rafa 
From: Rafael Vazquez <vazquez@im...>  20150513 07:23:54

Dear Eli, that's not surprising, since Bsplines (and NURBS) basis functions are not interpolatory, and their values are between 0 and 1. This difference between the solution vector (the control variables) and the plotted solution is analogous to the difference between the control points and the real geometry. In any case, for Paraview we are evaluating the solution exactly at a given set of points. If you use enough points, you will get an accurate plot of the computed solution. Rafa On 12/05/2015 23:49, John Eli wrote: > Dear all, > > Thanks for the nice suggestions. I have a question related the plot in > paraview. If one uses the function sp_to_vtk() for plotting, then in > the color menu of paraview one can see the upper and lower limit of > the solution vector e.g., u,. On the other hand if one find the > maximum and minimum of the solution vector itself, then one can see > that are too much different then what is shown in the vtk resolution. > I agree that it must not be equal as we evaluate the solution on > different points (vtkpnts) but it some how close to it? Is there a way > to compare what have been plotted by vtk and the solution or some > reasoning for that? For example I have some results where in the plot > I have the minimum = 0.0006 and maximum = 3.026 but if i find the > maximum and minimum of solution vector then it becomes 0.01273 and > maximum=3.4937. > > best wishes > Eli > >  > Date: Mon, 11 May 2015 17:19:47 +0200 > From: vazquez@... > To: john.eli90@...; geopdesusers@... > Subject: Re: [Geopdesusers] problem in an operator > > Dear Eli, > I am moving the discussion in the mailing list. > > What do you mean by having different test and ansatz functions? The > operators in general should work for any kind of test and trial function. > > The advection term was implemented directly in version 2. I don't know > if any other user has it, but if not you can implement it yourself as > an exercise. > > And yes, mesh.element_size(iel) should be the right quantity for the > scaling. > > Rafa > > On 11/05/2015 17:11, John Eli wrote: > > Dear Rafael, > > Thanks for your nice answer. I have got the three different types > of implementations for initial data from Martin, thanks to him. I > guess I will implement by myself now for the boundary terms. In my > operator actually the test and ansatz functions are different from > what have implemented in op_vel_dot_gradu_v and aditionally i have > to scale them by h_K (msh.element_size(iel) i guess is the right > field?). I will try to read the older version of the code and try > to understand. If you still have the older version of > op_vel_gradu_v. then kindly send me that or refer me from where i > should get. Thanks > > best > Eli > > 
From: John Eli <john.eli90@ho...>  20150512 21:49:29

Dear all, Thanks for the nice suggestions. I have a question related the plot in paraview. If one uses the function sp_to_vtk() for plotting, then in the color menu of paraview one can see the upper and lower limit of the solution vector e.g., u,. On the other hand if one find the maximum and minimum of the solution vector itself, then one can see that are too much different then what is shown in the vtk resolution. I agree that it must not be equal as we evaluate the solution on different points (vtkpnts) but it some how close to it? Is there a way to compare what have been plotted by vtk and the solution or some reasoning for that? For example I have some results where in the plot I have the minimum = 0.0006 and maximum = 3.026 but if i find the maximum and minimum of solution vector then it becomes 0.01273 and maximum=3.4937. best wishes Eli Date: Mon, 11 May 2015 17:19:47 +0200 From: vazquez@... To: john.eli90@...; geopdesusers@... Subject: Re: [Geopdesusers] problem in an operator Dear Eli, I am moving the discussion in the mailing list. What do you mean by having different test and ansatz functions? The operators in general should work for any kind of test and trial function. The advection term was implemented directly in version 2. I don't know if any other user has it, but if not you can implement it yourself as an exercise. And yes, mesh.element_size(iel) should be the right quantity for the scaling. Rafa On 11/05/2015 17:11, John Eli wrote: Dear Rafael, Thanks for your nice answer. I have got the three different types of implementations for initial data from Martin, thanks to him. I guess I will implement by myself now for the boundary terms. In my operator actually the test and ansatz functions are different from what have implemented in op_vel_dot_gradu_v and aditionally i have to scale them by h_K (msh.element_size(iel) i guess is the right field?). I will try to read the older version of the code and try to understand. If you still have the older version of op_vel_gradu_v. then kindly send me that or refer me from where i should get. Thanks best Eli 
From: Rafael Vazquez <vazquez@im...>  20150511 15:19:58

Dear Eli, I am moving the discussion in the mailing list. What do you mean by having different test and ansatz functions? The operators in general should work for any kind of test and trial function. The advection term was implemented directly in version 2. I don't know if any other user has it, but if not you can implement it yourself as an exercise. And yes, mesh.element_size(iel) should be the right quantity for the scaling. Rafa On 11/05/2015 17:11, John Eli wrote: > Dear Rafael, > > Thanks for your nice answer. I have got the three different types of > implementations for initial data from Martin, thanks to him. I guess I > will implement by myself now for the boundary terms. In my operator > actually the test and ansatz functions are different from what have > implemented in op_vel_dot_gradu_v and aditionally i have to scale them > by h_K (msh.element_size(iel) i guess is the right field?). I will try > to read the older version of the code and try to understand. If you > still have the older version of op_vel_gradu_v. then kindly send me > that or refer me from where i should get. Thanks > > best > Eli 
From: Rafael Vazquez <vazquez@im...>  20150511 14:01:04

Dear Eli, the advection term is already implemented in geopdes, in the file op_vel_dot_gradu_v. If that is not exactly what you need, you can try to create your function from this one. The functions to compute the matrices in version 2 are not easy to read, but in some of them (op_gradu_gradv, for instance) we have left, at the bottom of the file, an older version which should be much easier to understand. In general, plotting on the mesh lines does not make sense, because you will only get a piecewise linear function in a very coarse mesh. If you really want to do it, you can define the variable vtk_pts using the knot vector. For now, the best way we have to plot the solution is the one you can find in the examples. For the implementation of initial and boundary conditions you should ask if other users want to share what they have done. For smooth functions, an L2 projection should work fine. Regards, Rafa On 11/05/2015 12:29, John Eli wrote: > Dear All and Rafael, > > I am facing a problem to create a matrix for one of the form in my equation i.e., sum_K h_K (u, b.grad v)_K . Somehow this term looks similar as in the supg stabilization methods for convectiondiffusionreaction problem. I have found there some users is doing transient case. Can he help me with the initial and boundary data approximation. Another question is about the plotting. Is there a way to plot solution on the mesh? Or what is the better way to plot the solution? My file is attached here with. I will be very thankful for the nice suggestions and help. > > best > Eli > > > >  > One dashboard for servers and applications across PhysicalVirtualCloud > Widest outofthebox monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > > _______________________________________________ > Geopdesusers mailing list > Geopdesusers@... > https://lists.sourceforge.net/lists/listinfo/geopdesusers 
From: John Eli <john.eli90@ho...>  20150511 10:29:44

Dear All and Rafael, I am facing a problem to create a matrix for one of the form in my equation i.e., sum_K h_K (u, b.grad v)_K . Somehow this term looks similar as in the supg stabilization methods for convectiondiffusionreaction problem. I have found there some users is doing transient case. Can he help me with the initial and boundary data approximation. Another question is about the plotting. Is there a way to plot solution on the mesh? Or what is the better way to plot the solution? My file is attached here with. I will be very thankful for the nice suggestions and help. best Eli 
From: Rafael Vazquez <vazquez@im...>  20150508 08:26:27

Create a qn with one single element in each direction, and then create the msh. As far as I remember this is already what Pavel was using, not only for the boundary but for the whole domain. Rafa On 08/05/2015 10:24, Martin Ebert wrote: > Right, then how this will work for the all other element which are not > on the boundary using GeoPDEs? Could you give me a hint? Do I also > need to use as a qn in the whole domain? > > thanks > Martin > > On Fri, May 8, 2015 at 10:18 AM, Rafael Vazquez <vazquez@... > <mailto:vazquez@...>> wrote: > > Dear Martin, > yes, when computing the Greville points for the boundary in the > parametric domain, you only need to compute the averages for the > corresponding knot vector(s). In a 2D domain, it is the second for > x=0 and x=1, and the first for y=0 and y=1. > > Notice that there is not a nice correspondence between the number > of Greville points and the number of knots/elements. Pavel solved > this creating one single element with all the Greville points, but > he was giving the qn as a row vector (1 x nqn) instead of a column > vector (nqn x 1), which is the one we use in GeoPDEs. > > Regards, > Rafa > > > > >  > Martin Ebert 
From: Martin Ebert <ebert.marti@gm...>  20150508 08:24:57

Right, then how this will work for the all other element which are not on the boundary using GeoPDEs? Could you give me a hint? Do I also need to use as a qn in the whole domain? thanks Martin On Fri, May 8, 2015 at 10:18 AM, Rafael Vazquez <vazquez@...> wrote: > Dear Martin, > yes, when computing the Greville points for the boundary in the parametric > domain, you only need to compute the averages for the corresponding knot > vector(s). In a 2D domain, it is the second for x=0 and x=1, and the first > for y=0 and y=1. > > Notice that there is not a nice correspondence between the number of > Greville points and the number of knots/elements. Pavel solved this > creating one single element with all the Greville points, but he was giving > the qn as a row vector (1 x nqn) instead of a column vector (nqn x 1), > which is the one we use in GeoPDEs. > > Regards, > Rafa > >  Martin Ebert 
From: Rafael Vazquez <vazquez@im...>  20150508 08:18:27

Dear Martin, yes, when computing the Greville points for the boundary in the parametric domain, you only need to compute the averages for the corresponding knot vector(s). In a 2D domain, it is the second for x=0 and x=1, and the first for y=0 and y=1. Notice that there is not a nice correspondence between the number of Greville points and the number of knots/elements. Pavel solved this creating one single element with all the Greville points, but he was giving the qn as a row vector (1 x nqn) instead of a column vector (nqn x 1), which is the one we use in GeoPDEs. Regards, Rafa 