Diablo Mili plot file crashes when trying to view shared variables

[durrenberger1]

Jerome Solberg created a plot file using Diablo which has gap analysis for bricks and and particles. These become shared variables. When trying to do a psuedocolor plot selecting the shared variables the server crashes, sometimes on initial drawing other when I move a timestep. I can supply you with with the debug logs up to level 3 and the plot files on the RZ if needed. This is the error that occurred.

[brugger1]

Hi Kevin,

What version of VisIt are you using? The default on rzgenie is 3.1.4, but we have 3.2.1 installed, which has some mili improvements over 3.1.4.

If you’re using the latest version, then yes, the files and the level 3 debug logs would be helpful.

Eric

[durrenberger1]

Hi Eric, I tried it both the default 3.1.4 and version 3.2.1 I got the same result. I will give you the files on the RZ. Kevin

[brugger1]

@durrenberger1, I did some debugging and the crash is happening because the data from the mili file is being written outside of the array that it is storing the data into based on the metadata in the mili file.

Here is my overview of the mesh topology.

There is a strip of 10 hexes on top.
Below that is a strip of 10 shells on the lower boundary of the 10 hexes.
Below that is a strip of 10 shells.
Below that is a strip of 10 hexes on the bottom. The shells line up with the top surfaces of the hexes.

This give 40 elements total. 10 hexes, 10 shells, 10 shells, 10 hexes.

The variable we are trying to plot is "gap" and it is a element quantity that is only defined on the 2 sets of 10 shells.

It writes the first set of 10 values offset into the array of 40, 10 spots in. This is correct.
What I believe should happen is the next set of 10 values should be written into the array of 40, offset 20 spots. What is happening is that it is writing 22 values offset by 155.

Here is the information about "gap" in the mili file:

        "gap": {
            "LongName": "Nodal Gap",
            "num_type": 4,
            "agg_type": 1,
            "vector_size": 3,
            "dims": 0,
            "rank": 1,
            "Center": 1,
            "VTK_TYPE": 2,
            "vector_components": [
                "gap_x",
                "gap_y",
                "gap_z"
            ],
            "subrecords": [
                15,
                16
            ]
        }

Note the that it references subrecords 15, 16.
Here is the information that VisIt has read in about the subrecords 15 and 16.

AddSubrec: SRId=15,numEl=10,numDB=1
dBRAnges=11,20,
AddSubrec: SRId=15,numEl=10,numDB=1
dBRAnges=11,20,
AddSubrec: SRId=15,numEl=10,numDB=1
dBRAnges=11,20,
AddSubrec: SRId=15,numEl=10,numDB=1
dBRAnges=11,20,
AddSubrec: SRId=15,numEl=10,numDB=1
dBRAnges=11,20,
AddSubrec: SRId=16,numEl=22,numDB=1
dBRAnges=155,176,
AddSubrec: SRId=16,numEl=22,numDB=1
dBRAnges=155,176,
AddSubrec: SRId=16,numEl=22,numDB=1
dBRAnges=155,176,
AddSubrec: SRId=16,numEl=22,numDB=1
dBRAnges=155,176,
AddSubrec: SRId=16,numEl=22,numDB=1
dBRAnges=155,176,

The really strange this is that subrec 15 has 10 values, implying an element value, while subrec 16 has 22 values, implying a nodal value (10 connected shells give 11 rows of 2 nodes, giving 22 nodes total).
So the problem is that the values for gap are zonal for the first 10 shells and are nodal for the second 10 shells, which seems like it was unintended and won't work.

Subrec 16 should have 10 elements and a range of 21 - 30, assuming gap is an element value. I noticed that the long name is "Nodal Gap", so maybe the intent was for it to be a nodal variable. I'm not sure I know what the correct values would be in this case, but subrec 15 would definitely be wrong and subrec 16 might still have the incorrect range.

Thoughts on my analysis?

[markcmiller86]

Analysis seems great. I assume by this...

It writes the first set of 10 values offset into the array of 40, 10 spots in. This is correct.

You are meaning that the Mili plugin is writing these values to a vtk data array to be returned from the plugin to VisIt in a GetVar call?

It could be helpful if you could point to the lines of code you are talking about by going to the source. I assume you are talking about code at or around here,

visit/src/databases/Mili/avtMiliFileFormat.C

Lines 1508 to 1528 in 09309bf

	if (isShared)
	{
	//
	// If this is a shared variable, we need to retrieve data from
	// each of the classes that share this variable.
	//
	SharedVariableInfo *sharedInfo =
	miliMetaData[meshId]->GetSharedVariableInfo(shortName.c_str());
	if (sharedInfo != NULL)
	{
	std::vector<int> *varIdxs = &(sharedInfo->variableIndicies);
	for (std::vector<int>::iterator itr = varIdxs->begin();
	itr != varIdxs->end(); ++itr)
	{
	int curIdx = (*itr);
	MiliVariableMetaData *sharedVarMD =
	miliMetaData[meshId]->GetVarMDByIdx(curIdx);
	if (sharedVarMD->IsElementSet())

What does being a "shared variable" mean?

The error message pasted in orig. post shows its plotting a variable named Primal/Shared/gap_magnitude so that suggests its a vector variable and VisIt is computing the magnitude using expressions. So, is it maybe a 3-component quantity involved?

Can the data file be attached here?

[brugger1]

@markcmiller86 I am creating a pseudocolor plot of Primal/Shared/gap_magnitude as you mentioned, so it is reading in gap, which is a vector. It is then calculating the magnitude with an expression.

Regarding the location in the code. That spot is a bit higher in the call chain. The actual overwrite is located in the call to ReadMiliResults in this block of code:

visit/src/databases/Mili/avtMiliFileFormat.C

Lines 2279 to 2292 in 09309bf

	if (nBlocks == 1)
	{
	//
	// Adjust the start.
	//
	int curStart = start + blockRanges[0] - 1;
	int resultSize = nTargetEl * varSize;
	float *dbPtr = dataBuffer;
	ReadMiliResults(dbid[dom], ts, SRId,
	1, &varName, vType, resultSize,
	dbPtr + (curStart * varSize));
	}
	else if (nBlocks > 1)

The important variable values are:

start = 0
blockRanges[0] = 155
nTargetEl = 22
varSize = 3

I believe they should be:

start = 0
blockRanges[0] = 20
nTargetEl = 10
varSize = 3

The length of the array dataBuffer is length 120, so with blockRanges[0]=155, it writes outside the array bounds.

[durrenberger1]

Hi Eric,

So shared variables were added fairly recently to the plugin. If you have element which have a common variables say stress for bricks and shells they would be combined into a Shared menu item. We do this within Griz as we do not have the ability to render more than one element/variable otherwise. Alister was working on this prior to leaving to do the AI work he is currently doing.

This was to give analyst a familiar structure that they see in Griz.

The additional 'gap' elements for subrecord 16 are actually particles which resolve to nodal values for visit

[brugger1]

That additional information helps a lot! Especially that the additional gap elements are particles. If I understood the Mili file format I could probably figure this out myself, but it would be useful to know what the total nodes are for the problem and then all the elements for the problem.

My guess is that there are 10 hexes, 10 shells, 10 shells, 10 hexes, but I don't know how the particles fit in. Based on the block offsets I'm seeing, I assume there are more things going on, but I'm not sure.

Maybe a WebEx with @durrenberger1 , @markcmiller86 and I would be more efficient at this point.

[durrenberger1]

We can meet. But, I need to get with Diablo and see what they are trying to do. There are 2 particles per node and they used the long name Nodal which in itself won't effect things but it does not make sense. I need to know what they are trying to accomplish.

Also at the bottom of the .mili file is a section called Classes which list all the class info. Here is that section:

"Classes": {
"count": 6,
"node": {
"LongName": "Nodal",
"ElementCount": 88,
"SuperClass": 1,
"variables": [
"nodpos",
"nodacc",
"temp",
"nodvel",
"disp_iter",
"noddisp"
]
},
"quad": {
"LongName": "Quads",
"ElementCount": 20,
"SuperClass": 5,
"variables": [
"nodforce",
"nodnormpen",
"normgap",
"gap",
"nodpres"
]
},
"brick": {
"LongName": "Bricks",
"ElementCount": 20,
"SuperClass": 9,
"variables": [
"stress",
"eeff"
]
},
"mat": {
"LongName": "Material",
"ElementCount": 0,
"SuperClass": 10
},
"glob": {
"LongName": "Global",
"ElementCount": 0,
"SuperClass": 11
},
"particle": {
"LongName": "Nodal",
"ElementCount": 176,
"SuperClass": 13,
"variables": [
"nodforce",
"dx",
"dy",
"dz",
"nodnormpen",
"normgap",
"gap",
"nodpres"
]
}
}

[markcmiller86]

Maybe a WebEx with @durrenberger1 , @markcmiller86 and I would be more efficient at this point.

I can make myself available for that.

[durrenberger1]

Let me work with Diablo first. There is some things not correct with the output of the plot file. Kevin From: markcmiller86 ***@***.***> Sent: Tuesday, September 7, 2021 11:52 AM To: visit-dav/visit ***@***.***> Cc: Durrenberger, James K. ***@***.***>; Mention ***@***.***> Subject: Re: [visit-dav/visit] Diablo Mili plot file crashes when trying to view shared variables (#16993) Maybe a WebEx with @durrenberger1<https://urldefense.us/v3/__https:/github.com/durrenberger1__;!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY158lbk-a$> , @markcmiller86<https://urldefense.us/v3/__https:/github.com/markcmiller86__;!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY1-Pqc-lN$> and I would be more efficient at this point. I can make myself available for that. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<https://urldefense.us/v3/__https:/github.com/visit-dav/visit/issues/16993*issuecomment-914543722__;Iw!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY1-U1U4cl$>, or unsubscribe<https://urldefense.us/v3/__https:/github.com/notifications/unsubscribe-auth/AKX6GRC7XLZX6VR6DXPFCSTUAZNM3ANCNFSM5DHUIHXQ__;!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY1_8jnT4D$>. Triage notifications on the go with GitHub Mobile for iOS<https://urldefense.us/v3/__https:/apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675__;!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY1yWJBRyX$> or Android<https://urldefense.us/v3/__https:/play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign*3Dnotification-email*26utm_medium*3Demail*26utm_source*3Dgithub__;JSUlJSU!!G2kpM7uM-TzIFchu!lSSYm-MmA-BVE94WEmq3oLk1smp6IsUTmUS-qTvwP24RQekGz292VkpRO1kY1xez_zAx$>.