Preliminary Convergence data

I have preliminary results for a convergence analysis of a fillet in tension model.


I would say I am about half way through and I am a little perplexed at the results so far. I have been looking at two parameters in my evaluation: number of elements through the fillet radius and the order of the basis. Here are my data so far.


I feel there is something that I am missing in the model set up that is causing some slow convergence or perhaps a different aspect I need to understand better about spline based elements.

So far I have kept the same continuity and quadrature through all the models (C1 and QP+1) and the goal stress is ~187 psi

Thank you!

Clint this seems like an excellent study and we appreciate you sharing your results! I have to agree with you that those convergence results seem a little suspect, but without taking a closer look at what’s happening its impossible to diagnose the problem. If you’d like, you can send over a few of the coreform .json files that you ran and we’d be happy to take a closer look at what might be happening. If you sent a couple of the Quadratic C1 files that would give us a good understanding of the mesh and problem parameters that you used. Thanks!

I have my Json files split up in order to be able to input different models with the same model setup each time I run through a new mesh discretization (this makes model setup and execution time takes a few seconds rather than a few minutes). I would upload my .cub files but those are not listed as allowed right now on the forum. Give me till the afternoon and I can get a whole Json file with a model, but for now here is the model setup of my JSon files without geometry related cards.

As a brute force approach to increasing fidelity over the weekend I have increased the fidelity of the model a little bit by increasing my output to a Uniform15 callout (as opposed to a unifrom1 callout I had in the listed results) as well as changing the quadrature to Q10. These have improved the fidelity of the model in the lower resolutions I am running but I haven’t seen a drastic improvement in accuracy yet.

One caveat I need to mention is the models I am using were generated in Abaqus, exported to Trelis as a .sat file, meshed, then saved as a .cub file. The Coreform solver hasn’t yelled at me for using a 2D import as it did for the 3D imports I have tried. I had to build my 3D models in Trelis to resolve my issue there. Could it possibly be linked to unclean geometry generated in Abaqus?

Thank you!

Fillet Inputs.json (5.9 KB)

It’s absolutely possible that it’s related to a poor construction of the geometry, but I wouldn’t say the process you just described raises any immediate red flags. This process of using Trelis to create U-Spline meshes is still very new and needs quite a bit more work before we’d be ready to call it robust.

Thank you for pointing out that the system wasn’t letting you upload .cub files. I’ve changed the site settings so that you should be able to do this now, so if you could send over the .cub files you were using for your geometry that would really help us to diagnose the problem.


Here is the .cub file that I have used to generate the above data. The site didn’t let me upload the .cub file though so I relabeled it to a .json file. Change it back to a .cub file and it should be useable!

Fillet_5El - CUB_FILE.JSON (107.9 KB)

So I have reconfigured my data to look for the SigmaXX stresses in place of the principal stresses. The peak fillet stresses are close enough that I am able to get a good representation of the convergence of the x direction stresses (which is a scoche lower than the exact solution from Peterson’s). Here is a snippet of the data from the Coreform solver for a modeled fillet above with an increasing number of element through the radius of the fillet. The single element, mostly a curious adventure on my part, seems to give good results once a quartic basis function is used. Though the solution begins to stiffen as higher order bases are selected to represent the single element. Increasing the mesh to 2 elements seems to immediately resolve this issue.

Notice that the cubic, 1 element through the radius gives an outlier value. This was caused by an incorrect geometry read in from the import of the .cub file. I imagine the convergence plot will be much cleaner if I am able to remedy this outlier. Regardless, the results look good and definitely showcase a value of spline based elements over traditional FEA in flexibility of increasing the order.

Those results look great Clint! I’m glad you were able to find one that worked well. As you’ve clearly already figured out, our stress recovery and output need a significant amount of work. There are many ways to recover stress and what we’ve currently implemented needs a lot of work before we’re completely comfortable with it. You also made another post about the types of stress we can output as well. These are all things we’ll continue to iterate on as we go.

Another thing that I wanted to point out after reviewing your geometry is that even though I’m glad you’re seeing benefits with splines, there are still things we could do with your meshes to increase the smoothness in important areas. As an example of this, note the screenshot below:

The vertices I’ve circled are extraordinary points only one element away from the smooth circular edge. All the edges around these points must be creased removing the benefits of having smoothness across those edges. This is not to say that you did anything wrong, but that hopefully in the future we can develop better meshing techniques so that you can have higher order smoothness in the most important regions of your geometry.

Good point on the extraordinary points. I will see if I can rework my mesh to remove them from the area that I am concerned with.

I look forward to the novel meshing techniques that take advantage of the flexibility of spline based elements as compared to their FEA brethren. Nut for now, we do the best with the tools we have available.