Long delay

[JohnNichols]

I am amending my FE generation program.  I have a large 3D array that holds all of the FE element types, it is called ElementType. 

In both compilers on all my versions of VS 2022, it is very slow to open the local variable - about a minute, I realize this is a large array, but the computer just stops till it opens.   It hangs the whole computer. 

PS You can no longer get VS 2019 Community that I can find.  

And can some one tell me how to turn off the annoying deprecated message in IFORT, sometime you want to check something such as uninitialized variables. 

[andrew_4619]

/Qdiag-disable:10448

What do you mean by "open the local variable"?  Expand it in the watch window maybe?

[jimdempseyatthecove]

I cannot attest to the behavior of your version of MSVS, but the older versions of MSVS would "clip" large arrays to about 1000 elements.

(you had to enter subsections of the array)

The newer versions seem to not do this. I suspect that MSVS is now not clipping, but instead converting the binary numeric values to text, then showing only the portion that fits in the sub-window (locals in this case)...

as opposed to

converting only those variables exposed in the view pane at the time of viewing.

While this follows the OHIO rule (Only Handle It Once), as you are experiencing, in some cases it becomes an aggrivation.

Should your data be REAL(8), the array would be 3.7GB, and the conversion to text would extend the storage to about 3x to about 11GB.

Suggestion, perform Quick Watch (or Watch), and enter the subscript sections of interest. Example

ELEMENTTYPE(:,1,1)

to look at the 1st row

Before you "Uggg" this, consider how much time you would spend scrolling the whole array to get to the point of interest.

Jim Dempsey

[JohnNichols]

Jim:

I tried that as I only wanted to look at 1,1,1, and it would not come up in the watch window, it just hung.  

It does finally show up in the local window but your computer is hung whilst it does it.  

I realize it is a large array, now I will just printout the result to the screen it is faster.  

I did not have this problem last time I used the file about 12 months ago.  

Thanks

John

The other interesting issue on debugging is the following screen that it shows as it moves between source files.   It will tell me sourcea.f90 is not available and then it opens it after I close this window.  

Perhaps Intel needs to update the VSIX file. 

[jimdempseyatthecove]

Does your mouse hover show contents of ElementType(I,J,K):

dummy = ElementType(I,J,K)

If so, then add 3 integer variables for use as indices, place break on statement, vary contents of the indicies.

You could also use ranges.

If hover does not show content, then do single step past dummy=, examine dummy, reset indicies to next value of interest, use Set Next Statement to back up to dummy= line, single step, rinse and repeat.

Or, with a little more work, add a contained subroutine that receives a ~smallish 1D array, and insert a call to it with a slice of the array

call foobar(ElementType(:,1,1))

.or.

if(debugThis) call foobar(ElementType(:,1,1)) ! debugThis is a logical with SAVE attribute

.or.

if(debugThis) call foobar(ElementType(:,J,K)) ! debugThis is a logical with SAVE attribute

Jim

[andrew_4619]

The watch windows used to evaluate a max of 100 elements (I think it was 100)  of an array. I was surprised that that limit has been removed. A human cannot look at 432,000,000 elements of an array so it is pointless to try to support that.  I have not seen this problem until I went looking for it just now and found it. I think the reason is that I never user the "locals" window it contains a forest of things in a more complex application, I always target specific trees of interest in the watch window and that includes array slices. when one considers how much data 432,000,000 items of 4 or 8 bytes occupies it is unsurprising that trying to visualise it takes some time! 

[JohnNichols]

I am now running VS 17.12.0 Preview 2.1, so the comments are based on that use.  

If I click on the locals window it now takes as long as it takes to make a screen shot to open the elementtype. 

About 40 seconds, I am a bit slow.  

About 30 seconds to move this far, but it is not useful as the array is to large and so you use Jim's ideas or write(*,*)

If I click on Line 165 (red arrow) elementtype opens in a window immediately, but one would not scan down.  

I realize it is a large array, but I need it to represent a FEM model as a set of integers, imagine a box, say 200 m in the X and 20 m in the Y and 60 m in the Z axes, and you want to model representative units that are 0.1 m cubes,  it is very easy to drop an integer into the FEM position and then draw the cubes in Fortran quickly in the correct place.  Most structures are rectilinear so it is easy, even arches.  

A zero is blank space, you work from the bottom up, the control file is short,  this is just to start the planks on a gunboat.  

Try modelling oakum.  Even a large bridge is not more than 300 lines of text, and you can see the model in Autocad and the FE drawer.   Much better than Python in Rhino or STL transfers. 

Philadelphia
**DR
1
**TH
0.05
**NX
4
**DX
0.1
**NY
3
**DY
0.1
**NZ
1
**DZ
0.05
**NP
11

[AlHill]

Nice work, John.

Doc (not an Intel employee or contractor)

[JohnNichols]

Thank you.

[JohnNichols]

With IFX in compiling Beowulf, I now get an output file a.txt.  I do not create a.txt, I do not write to it and I have no idea how to get rid of same.  

It looks like a Fortran file from the program compilation. 

Any ideas welcome?

[jimdempseyatthecove]

That is a linker load map file.

List your command line arguments.

Jim Dempsey

[JohnNichols]

Interesting, do not remember this option.