<div dir="ltr"><div>I'm glad you found a solution! <br></div><div>Thank you for sharing how you solved it, that will be helpful for many, many other people. <br></div><div>I've also had some trouble with matching the right number of data points with the given plot type (e.g. vectors of 9 coords for tensor data etc)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 18, 2019 at 1:07 PM walter steffe <<a href="mailto:walter.steffe@alice.it">walter.steffe@alice.it</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I have found the problem with the PView, it was my fault.<br>
<br>
The function getKeysValues(sf_ele, keys, values) I had used is that one defined in gmsh-4.4.1-source/demos/api/adapt_mesh.cpp:<br>
void getKeysValues(const std::map<std::size_t, double> &f,<br>
std::vector<std::size_t> &keys,<br>
std::vector<std::vector<double> > &values)<br>
{<br>
keys.clear();<br>
values.clear();<br>
for(std::map<std::size_t, double>::const_iterator it = f.begin();<br>
it != f.end(); it++){<br>
keys.push_back(it->first);<br>
values.push_back(std::vector<double>(1, it->second));<br>
}<br>
}<br>
<br>
The vector associated with a tag (which in my case corresponds with a tetreahedron) has length 1 because the scalar field is constant over the element.<br>
But in my code "listdata.insert(listdata.end(),values[i].begin(),values[i].end())", I was supposing that values[i] contains 4 numbers (the values associated<br>
with the 4 tetrahedron vertices). And my assumption was wrong.<br>
<br>
Anyway now I have switched back to the field based on the PViewDataGModel (as done in gmsh-4.4.1-source/demos/api/adapt_mesh.cpp:).<br>
This solution is more efficient (less memory usage) and finally it works well after having set the current model.<br>
<br>
<br>
Walter<br>
<br>
<br>
<br>
On Mon, 2019-11-18 at 07:13 +0100, walter steffe wrote:<br>
> Hello Max, thanks for your replay.<br>
> <br>
> The mesh field settings follws the example given in gmsh-4.4.1-source/demos/api/viewlist.cpp. The only differencex being that I have used <br>
> scalar tetrahedrons (SS) instead of scalar treiangles (ST). <br>
> From that example I have understood that the format of data vector has to be:<br>
> <br>
> tet1_V1x, tet1_V2x, tet1_V3x, tet1_V3x, tet1_V4x, tet1_V1y, tet1_V2y, ... tet1_V4z, tet1_val1, tet1_val2, tet1_val3, tet1_val4,<br>
> tet2_V1x, ....<br>
> <br>
> Regarding the sharing of my code (which is called EmCAD) it is possible but it would require some work that I was planning to do in the next future.<br>
> A few years ago I published an old version of EmCAD (see <a href="https://github.com/wsteffe/EmCAD" rel="noreferrer" target="_blank">https://github.com/wsteffe/EmCAD</a>) but after that I made a lot of changes and I should update it to<br>
> the<br>
> most recent stable version.<br>
> <br>
> The generated pos file is quite big (about 10 MB) but the first two lines are the following:<br>
> <br>
> View "mesh size" {<br>
> SS(46.83944890393698,-37.88756912800455,27.48312772362366,47.34769558079194,-37.83372365566942,27.69034188350719,46.76329291980484,-<br>
> 37.58650617307168,27.60072813488528,46.97847752964434,-37.72705133636931,27.85320246718948){0.6408381837974682};<br>
> SS(45.9160848845363,-38.60456203454583,31.84977417926594,46.83102692685463,-38.97962021517143,31.85091832450902,46.00960755639631,-<br>
> 39.51314340935686,31.79892854402282,46.27960884215373,-38.86612166745061,30.90869736302538){1.042203762895043};<br>
> <br>
> <br>
> Previously I have tried using a PViewDataGModel based field. <br>
> The printed pos file was the same but the computation of mesh size still wrong.<br>
> In that case it failed inside the function PView *getView() const. This function exited after entering inside of the following lines:<br>
> if(v->getData()->hasModel(GModel::current())) {<br>
> Msg::Error(<br>
> "Cannot use view based on current mesh for background mesh: you might"<br>
> " want to use a list-based view (.pos file) instead");<br>
> return 0;<br>
> }<br>
> <br>
> But now I am thinking that probably this was because the current model was not switched to the new one (using gmsh::model::setCurrent())<br>
> and was still pointing to the model used for the setting of the PViewDataGModel.<br>
> <br>
> Anyway it is strange that the computation of a field based on the PViewDataList gives wrong results.<br>
> <br>
> <br>
> Walter<br>
> <br>
> <br>
> <br>
> On Sun, 2019-11-17 at 13:06 -0500, Max Orok wrote:<br>
> > Hi Walter, <br>
> > <br>
> > My first impression is that it looks like you might indeed be setting the mesh field value using the mesh coordinates. <br>
> > <br>
> > It's a little difficult to debug without an actual runnable program or the pos file that shows everything is OK.<br>
> > Would you mind sharing your program and pos file? <br>
> > <br>
> > Sincerely, <br>
> > Max <br>
> > <br>
> > On Sun, Nov 17, 2019 at 4:49 AM walter steffe <<a href="mailto:walter.steffe@alice.it" target="_blank">walter.steffe@alice.it</a>> wrote:<br>
> > > Hello everyone, I am still experimenting with adaptive meshing and I wanted to set a background field based on a PView.<br>
> > > I have build the view and related background field with the following code:<br>
> > > <br>
> > > <br>
> > > //sf_ele, and getKeysValues are the same as in gmsh-4.4.1-source/demos/api/adapt_mesh.cpp<br>
> > > getKeysValues(sf_ele, keys, values);<br>
> > > <br>
> > > <br>
> > > int viewTag = gmsh::view::add("mesh size");<br>
> > > <br>
> > > const std::vector<double> listdata;<br>
> > > int nelem=keys.size();<br>
> > > for(int i=0; i<nelem ; i++){<br>
> > > int etag=keys[i];<br>
> > > for(int j=0; j<mesh.elements()[etag]->nodesNum(); j++) listdata.push_back(mesh.elements()[etag]->nodes()[j]->x());<br>
> > > for(int j=0; j<mesh.elements()[etag]->nodesNum(); j++) listdata.push_back(mesh.elements()[etag]->nodes()[j]->y());<br>
> > > for(int j=0; j<mesh.elements()[etag]->nodesNum(); j++) listdata.push_back(mesh.elements()[etag]->nodes()[j]->z());<br>
> > > listdata.insert(listdata.end(),values[i].begin(),values[i].end());<br>
> > > }<br>
> > > gmsh::view::addListData(viewTag, "SS", nelem, listdata);<br>
> > > <br>
> > > <br>
> > > // just to check the data: <br>
> > > gmsh::view::write(viewTag, "data.pos");<br>
> > > // It seems OK<br>
> > > <br>
> > > ...<br>
> > > <br>
> > > GModel *gm0=new GModel();<br>
> > > #importing of OCC geometry ...<br>
> > > <br>
> > > ...<br>
> > > <br>
> > > <br>
> > > FieldManager *fields = gm->getFields();<br>
> > > int fieldTag=1;<br>
> > > Field *size_f=fields->newField(fieldTag, "PostView");<br>
> > > size_f->options["ViewTag"]->numericalValue(viewTag);<br>
> > > fields->setBackgroundFieldId(fieldTag);<br>
> > > <br>
> > > <br>
> > > gm->mesh(1); <br>
> > > gm->mesh(2);<br>
> > > gm->mesh(3);<br>
> > > <br>
> > > <br>
> > > The problem is that the field computed in BGM_MeshSize is WRONG.<br>
> > > <br>
> > > Following lines are taken from BackgroundMeshTools.cpp:<br>
> > > <br>
> > > double BGM_MeshSize(GEntity *ge, double U, double V, double X, double Y,<br>
> > > double Z)<br>
> > > {<br>
> > > ....<br>
> > > // lc from fields<br>
> > > double l4 = MAX_LC;<br>
> > > if(ge){<br>
> > > FieldManager *fields = ge->model()->getFields();<br>
> > > if(fields->getBackgroundField() > 0) {<br>
> > > Field *f = fields->get(fields->getBackgroundField()); <br>
> > > if(f) l4 = (*f)(X, Y, Z, ge);<br>
> > > }<br>
> > > }<br>
> > > <br>
> > > ..<br>
> > > }<br>
> > > <br>
> > > <br>
> > > I have debugged the code going inside of that computation and I have found that, quite often, it happens that <br>
> > > the value returned by (*f)(X, Y, Z, ge) coincides with the coordinate (x,y,or z) of a vertex used in the view data.<br>
> > > <br>
> > > This could be produced by a wrong ordering of data passed to gmsh::view::addListData.<br>
> > > But the data file printed by gmsh::view::write(viewTag, "data.pos") seems good and the values are not exchanged with <br>
> > > the coordinates.<br>
> > > <br>
> > > So I do not understand where is the problem. May you please give me a hint ?<br>
> > > <br>
> > > <br>
> > > Thanks in advance,<br>
> > > Walter Steffè<br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > <br>
> > > _______________________________________________<br>
> > > gmsh mailing list<br>
> > > <a href="mailto:gmsh@onelab.info" target="_blank">gmsh@onelab.info</a><br>
> > > <a href="http://onelab.info/mailman/listinfo/gmsh" rel="noreferrer" target="_blank">http://onelab.info/mailman/listinfo/gmsh</a><br>
> > <br>
> > <br>
<br>
<br>
_______________________________________________<br>
gmsh mailing list<br>
<a href="mailto:gmsh@onelab.info" target="_blank">gmsh@onelab.info</a><br>
<a href="http://onelab.info/mailman/listinfo/gmsh" rel="noreferrer" target="_blank">http://onelab.info/mailman/listinfo/gmsh</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div>Max Orok</div><div>Contractor<br></div></div><div dir="ltr"><a href="http://www.mevex.com" target="_blank">www.mevex.com</a><br><br><img src="https://docs.google.com/uc?export=download&id=1fHTIiW4OMUjQr1iOkspQ7wiEsxunoOs0&revid=0B6x5w-5zVaEjSkpwbm5oY29jbG1XMzJoYldXTmJpNGFtb3dVPQ" width="164" height="42"><br></div></div></div></div></div></div>