Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Writing tags to a mesh without having to convert to a field #250

Closed
a-jp opened this issue Sep 9, 2019 · 8 comments
Closed

Writing tags to a mesh without having to convert to a field #250

a-jp opened this issue Sep 9, 2019 · 8 comments

Comments

@a-jp
Copy link
Contributor

a-jp commented Sep 9, 2019

Hi,
Based on this post tags/fields I was trying to learn about tags and fields. However, I do not seem to be able to get a tag written to a mesh, I seem to have to always convert it to a field. Is that intended? If so, how to I store integer based fields? I am using the following:

apf::MeshTag *create_int_tag(apf::Mesh *m, int dim)
{
	apf::MeshTag *tag = m->createIntTag("my_tag", 1); // 1 is size of tag
	apf::MeshEntity *elem;
	apf::MeshIterator *it = m->begin(dim);
	int vals[1];
	vals[0] = PCU_Comm_Self();
	while ((elem = m->iterate(it)))
		m->setIntTag(elem, tag, vals);
	m->end(it);
	return tag;
}

So firstly this never appears in the vtk output, secondly, if I try to adapt the convert_my_tag function in the above link to be integer based so that I can see it in the vtk file, I can't because I don't seem to be able to write integer based values. Is there something I'm doing wrong? There does not seem to be an apf::INTEGER, do I always have to cast to double? It works fine if I do, but I wanted to check.

Finally, can I ask, is this following (which I'm using) the correct way to store a single double precision number per cell/element?

apf::createField(m, fieldName, apf::SCALAR, apf::getConstant(dim));

I found that in this link. I am looking for something that will have ghost allocation automatically created and exchanged. My code is a cell-entered (collocated) finite volume code. I just want to store say pressure in every cell/element and be able to do parallel exchange on that variable automagically.
Thanks,
Andy

@jacobmerson
Copy link
Contributor

I'm not a core developer, so take what I say with a grain of salt...but I think under the hood fields are actually stored on the mesh as tags, unless they are frozen in which case they are stored as arrays.

The underlying field infrastructure supports other types, however I think that only double fields are exposed to the user. @wrtobin has pull request #234 which deals with complex field support so he might be able to give some insight into what the current thought process is on how to bring field typing to the c-style apis.

In terms of writing tags to vtk it looks like we don't do it currently. You can look at the details of how we write out here. I suspect adding the capability to write tags shouldn't be too challenging.

@cwsmith
Copy link
Contributor

cwsmith commented Sep 10, 2019

@jacobmerson is correct: fields are implemented with tags, and tags cannot be written to vtk without first converting them to fields

As you discovered, fields don't support an storing integers and converting to a double is required.

The field call you pasted will associate a double with each element. Here is another example use:

core/test/create_mis.cc

Lines 27 to 29 in 59d0316

//We will create a field with the coloring as the values on each element
apf::Field* coloring = apf::createField(m,"colors",apf::SCALAR,
apf::getConstant(m->getDimension()));

Would you please expand a bit on what is needed with relation to ghosting and fields? Do you need a parallel synchronization routine where owned elements update the field values for all their ghost copies?

@a-jp
Copy link
Contributor Author

a-jp commented Sep 10, 2019

Thank you @jacobmerson and @cwsmith. I'm fine to construct a field, just wanted to make sure I was getting expected results.

Do you need a parallel synchronization routine where owned elements update the field values for all their ghost copies?

That's exactly right. I meant to say, if I do construct a field this way, and then construct ghost cells (which I'm having a segfault from so that will need to be a separate question), will the field be given an allocation within the ghost elements automatically, and will there be, on a suitable call to a synchronization routine, an exchange of the data? Could you give me an example of the synchronization call that exchanged a SCALAR assuming the above is correct?

So to be clear:

 apf::createField(m,"colors",apf::SCALAR, 
                                         apf::getConstant(m->getDimension()));

is the way to allocate field data for elements if I'm trying to hijack PUMI for a cell-centered FVM code?

@cwsmith
Copy link
Contributor

cwsmith commented Sep 12, 2019

@seegyoung Do we support field synchronization with a ghosted mesh?

@seegyoung
Copy link
Contributor

Yes, all field operations are supported with ghosted mesh.

@a-jp
Copy link
Contributor Author

a-jp commented Sep 12, 2019

So

apf::createField(m,"colors",apf::SCALAR, 
                                         apf::getConstant(m->getDimension()));

is the correct way to attach data to the cells/elements of a distributed mesh for which I want to have ghosted synchronization?

Is this the way to allocate field data for elements if I'm trying to hijack PUMI for a cell-centered FVM code?

Could you give me an example of the synchronization call that exchanged a SCALAR assuming the above is correct?

@cwsmith
Copy link
Contributor

cwsmith commented Sep 25, 2019

#245 has an example of scalar (double) field creation and sync

@cwsmith
Copy link
Contributor

cwsmith commented Sep 25, 2019

This seems to be resolved for now. Please reopen if needed.

@cwsmith cwsmith closed this as completed Sep 25, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants