Trying to adapt a Mecway-generated .inp file for Calculix

DaveStupple

I have a static thermal model that solves fine in Mecway. I would like to adapt it for Calculix so I can have orthotropic and temperature-dependent CTC. There is internal heat generated near the top surface, and convection on the bottom. Mecway does not export convection conditions to Calculix, so I need to manually amend the .inp file. I am hoping that Mecway 6 beta will successfully deal with the pyr6 elements that are part of my model. First thing I want to do is to get the model solved as is (without the fancy CTC), 

Just for interest, when I try to use the Calculix solver direct (with no manual convection from Mec6 beta, no solution is found and the Calculix output is full of errors like this:

*ERROR in e_c3d_th: nonpositive jacobian
determinant in element 13128

A non-exhaustive check on the elements that have this error appears to show that they are all pyr13 and all are the same material, having a temperature-dependent CTC. As far as I can see, pyr13 elements with non-temperature-dependent CTC are not listed with this error.

But I never expected the model to solve properly anyway, because the convection condition is not exported. So, I ploughed on and made the following changes to the .inp file:

1. I removed a few lines such as:

*NSET,NSET=Aluminium

*SURFACE,NAME=Cooled

which corresponded to named selections in the Mecway model and were not referred to elsewhere in the .inp file, so I figured they were redundant

2. I removed a set of lines similar to

*ELSET,ELSET=CVDD_fine

which were defining the regions with internal heat constraints from my Mecway model. The internal heat is defined later in the .inp file without reference to the above ELSET definitions, so I concluded that these were redundant. Other ELSET definitions that are later used to assign materials were left in place.

I think the *CFLUX section is the internal heat generation, but I could not understand why some of the values are negative. When I add up all the figures they add up to my total heat flux in watts, so I assume that the negative figures are a legitimate artefact of the conversion from flux/volume to flux/node.

3. After the *CFLUX definitions I inserted a *FILM section to represent convection at 3000 W per metre squared, with a cooling fluid at 10°C. The elements and surfaces were defined by adapting the appropriate ELSET (named selection), but changing all the surfaces from S to F. The first few lines are like this:

*FILM

65214,F3,283.15,3000

65215,F3,283.15,3000

65216,F3,283.15,3000

65217,F3,283.15,3000

65218,F3,283.15,3000

When I run this .inp file from file explorer (by double clicking), I get a cmd.exe window with a bunch of warnings along the lines of:

WARNING: in readccx() INI_FIELD_SIZE:5000000 to large and is reduced

Followed by line after line of errors, e.g.:

ERROR in seta: set Cr_interlayer, elem:64486 does not exist, min:2147483647 max:0

When I run from the Calculix command line (ccx filename), I get a promising start, leading to a statement about using 1 CPU to perform the heat flux calculation, but then we have a load of our old friends, the nonpositive jacobean determinant:

  *ERROR in e_c3d_th: nonpositive jacobian

        determinant in element       22601

To check whether some of the stuff I had edited out was important, I went back to the original .inp generated by Mecway and just added the *FILM constraint. This gave similar results.  My final punt was to change the temperature-dependent CTC to a non-temperature-dependent CTC - this didn't help.

No idea how to proceed. Attached is the .inp file with some of the modifications described above (stuff removed, *FILM added, temp-dependent CTC). I understand that people don't have time to plough through the details, but if anyone could make any suggestions of where I am going wrong, I would be very grateful.

Sergio

Have tried to import the model in Mecway with no success, my advice is to start with a small model (few nodes/elements) in order to investigate the boundary conditions with quick runs and after improve the mesh. I would avoid the piramids elements.

Regards

Victor

1., 2.

That's OK to delete the unused sets.

> I think the *CFLUX section is the internal heat generation, but I could not understand why some of the values are negative. When I add up all the figures they add up to my total heat flux in watts, so I assume that the negative figures are a legitimate artefact of the conversion from flux/volume to flux/node.

Yes. It converts internal heat generation to *CFLUX and distributed loads applied to individual nodes of quadratic elements need to be weighted in a funny way where some end up negative.

3.

I don't see anything wrong with the *FILM card. I would correct the non-positive Jacobian problem first and get it to solve at all before adding new things. You could put a fixed tempeature anywhere instead of the convection if that's preventing solving.

The non-positive Jacobian problem seems to be caused by the small dimensions of the mesh together with thermal analysis. For some reason CCX is OK with those pyramid elements when they're scaled up by 10^6 and it's OK with them for static analysis, but not as they are. This is going to be ugly to work around because Mecway writes all dimensions to CCX in meters, so if you scale it all up, you'll have to remember what units are used for everything. Not impossible though.

DaveStupple

Hi Sergio,

Thanks for taking a look. The model has internal heat in a thin film, and within the thin film the heat has both a vertical and a horizontal distribution (modelling the heating effect of an electron beam). This is the reason for such small elements. As we move away from the heating zone, the small elements grade up into larger, and the pyramids are essential for this. I have tried to find alternative patterns of grading, but failed. I can't use all small elements because the node count would be ridiculous (it's pretty bad now). I am not sure how I would start to approach this with a smaller model, but I will give it some thought. It might be worth trying with linear elements rather than quadratic. Anyway, thanks again .

Hi Victor,

When you say OK for static analysis, does this mean non-thermal? To scale this up then, does this mean:

1. All co-ordinates in the *NODE section multiplied by 10^6. I guess I could do this with Mecway's scale function then export to generate an .inp file to work with?

2. The internal heat would scale itself with the volume, giving me 10^18 times the total watts.

3. The available convection  area would scale by 10^12, but with 10^18 times as many watts to shift, I would need to scale the coefficient by 10^6.

4. The thermal conductivity would need to scale by 10^18. This figure comes from a simple trial using Mecway 6, and it seems to work, but I am unable to justify this logically... scale by 10^6 for each spatial dimension perhaps?

I'm not sure 1. that the convection is giving me a problem (the .inp with no added *FILM failed as well) 2. that a fixed temperature would be helpful. I'll give the above scaling a try unless I hear different from you guys.

Thanks!

Sergio

How are you working with this huge model? What are you using to preprocess?

Regards

DaveStupple

Hi Sergio, 

I'm not sure I understand the question! I created the model with Mecway, meshing manually. The model solves fine in Mecway and gives feasible results. I don't know what you mean by preprocess, so I guess that means there is no preprocessing.

The vertical heat distribution within the thin film was modelled by Monte Carlo analysis, and the horizontal distribution modelled to a close approximation of a Gaussian beam, with lots of assumptions about material properties etc.

By the way, I tried to scale the model by 10^6 but solving in Mecway has not given me the same results  as on the smaller scale, so something is not working.

Victor

I don't quite know how to scale all the quantities properly they way you did but the way I would do it is to choose a coherent unit system like μm,kg,s,K and use that for all quantities but tell Mecway that it's m,kg,s,K. If I've done my maths right, that would be:

Quantity Unit Unit set in Mecway

Length μm m

Mass kg kg

Time s s

Temperature K K

Thermal conductivity μW/(m.K) W/(m.K)

Heat flow rate pW W

Convection coeff. W/(m^2.K) W/(m^2.K)

Internal heat gen. MW/m^3 W/m^3

DaveStupple

Hi Victor,

Scaling the quantities 'properly' like I did failed to work, but when I followed your recipe , it worked perfectly and the model solves in Mecway to give the same temperatures as the original. I haven't worked out why you scaled the units the way you did, but your maths was certainly right. So that's a good start, I'll report back how I get on with Calculix. Thanks a lot.

Sergio,

If you meant how was I manipulating the inp file, I did some with SciTE, but I found it so unstable that I ended up doing most of it with Notepad, which is not so good because there's no collapsing of the subsections.

Sergio

Dave, I didn´t have any issues with SciTE, the only thing is that for colapsing such a big subsections will freeze the program on my pc. On the other side, Mecway refuses to open directly, that's why I was concerned on how you would be doing it.

Regards.

Victor

Dave: I converted each unit to its base units such as

W/m^3 = kg/(s^3.m)

then replaced m with μm, getting

kg/(s^3.μm)

= MW/m^3

Sergio: I think the file doesn't open because it has thousands of individual node loads that Mecway is blindly trying to create named selections and loads for. That's overloading it for opening, but it would have been able to generate and write the file OK to begin with, and then you'd have to edit it manually from then on.

DaveStupple

Gentlemen, this is great progress. I have the scaled-up model solving in CCX giving very similar temperatures to the Mecway solution. This model includes the material with the temperature-dependent CTC. Excellent news, thanks for your help so far.

I have found SciTE less prone to crashing if I 'toggle folds' through the dropdown menus rather instead of clicking on the tree. 

DaveStupple

When I plot the temperatures node-for-node from the CCX model against the temperatures from the Mecway model from which it was generated, I get a very nice fit along the X=Y line as I would hope. This tells me that the models are returning near identical results. There is a non-random pattern in the residuals, and I am not sure of the significance of this, but as the fit is good and the residuals small I am not particularly concerned. The individual 'lines' in the residuals might correspond to the different materials. 

When I do a node-for-node plot of heat flux (X direction), I get a reasonable fit on X=Y, there are a number of nodes at the top right of the plot where the Mecway fluxes do not vary with the CCX fluxes. I know the figures aren't in themselves meaningful as they are from scaled models (1e6 times original size), but it is an interesting pattern. I tracked down one of the nodes from near the top of the plot and found it to be in the X=0 plane of the model, with no material in the positive direction; the plane X=0 represents a plane of symmetry in the 'real life' assembly and so the model is truncated here, and zero net heat flux across this plane is assumed. I find it strange that a node with no material in the +X direction has a modest but positive heat flux in the X direction... I suppose it must cancel itself out in the grand scheme of things. 

The non-trend nodes on the Mecway-CCX heat flux plot represent heat flux values that are relatively small, and the good agreement of the temperature plot suggests the model has translated well to CCX. I'm not sure if I have anything to be concerned about here, but I am always happy to hear others' thoughts.

Good weekend all!

DaveStupple

Looking at the trend line of the temperature plot I notice that gradient 1 and intercept 0 are outside the given uncertainty intervals (I have not looked this up, but I would presume they are 95%). So there does seem to be a systematic difference between CCX and Mecway results, albeit small.

Victor

For the heat flux at the boundary,  I think CCX calculates heat flux at the element integration points then extrapolates to the nodes whereas Mecway does it directly at the nodes. That might be the reason for the difference but I would still expect Mecway to show some non-zero heat flux through the boundary since the actual temperature field is unlikely to be perfectly quadratic (assuming quadratic elements) across an element. If you find that the bigger elements have the bigger error, then it makes sense and is nothing to worry about - just refine it away if it's a problem.