Ability to generate lineloads along different axis

[khalilsb]

Currently lineloads are defaulted to be along the x direction. It would be beneficial to make this an input in the case of extracting lineloads in other directions for example for a wing in the spanwise direction

[nasa-ddalle]

Yes, this is a great idea. Definitely triload can support that (and also using an arbitrary vector to define the cut planes), but let me see how quickly this can be integrated into CAPE. It's definitely worth doing, and I'm already planning an overhaul of the line load database code. But it might be something easy (at least to set it to y or z) that can be done before the overhaul.

[nasa-ddalle]

I think this will work for now if you set "CutPlaneNormal" to "y" in the "DataBook" definition for your component. It will look kind of weird in the DataBook because it will still refer to the coordinate as "x" in the output files, but you should be able to verify that it's actually doing what you want by looking at the .triq files or other output files created by triloadCmd in the lineload/ folder within an individual case.

[khalilsb]

thanks for the update! I gave this a try with the latest version of cape and was running into an issue where cape is not running triloads due to not having enough iterations, this seems to be different behavior than cape v1.0. I thought lineloads were extracted from the latest boundary*plt

        // Line load
        "ll_wing": {
            "Type": "LineLoad",
            "CompID": ["wing_py","wingtip_py"],
            "CutPlaneNormal": "y",
            "nCut": 200
        },    

Here is the output from cape

    pyfun --ll

    oml192_rev0_de_py+00_de_ny+00_ds_py+00_ds_ny+00_dr+15/m0.30a21.0b0.0
      Not enough iterations (None) for analysis.

[nasa-ddalle]

Took me a while to figure out what was happening here ... The commits on this page

https://github.com/nasa/cape/commits/main/cape/pyfun/case.py

b/w 3/22 and 3/25 should fix this issue. CAPE was finding the {PROJECT}_tec_boundary.plt file but wasn't able to figure out what iteration it came from. Now it should be able to do that and also be smarter about a few other metadata situations. I've only updated this function on the main branch; back-porting it to v1.1 would be some work.

[khalils2]

Just recently updated cape to v1.2 and it looks like SectionType is longer a lineload input. Can this be added back?

[nasa-ddalle]

I'm curious if there's a particular setup that's not working? My testing still has "SectionType" in v1.2... Maybe there's a subtler problem with the way your JSON file is being read? I think there was a small change to how the options are read, so I might have made a mistake there.

[khalils2]

As i was writing this up i found the typo that caused the error! Apologies for the false alarm

But since upgrading i was getting some odd warnings regarding numpy, not sure what has changed here, might be something on my end

[nasa-ddalle]

Ah! A hard-to-see typo.

It looks like there's a NumPy 2.0 now ... and I might have to rewrite the extension a bit. For now, it might be easiest to just use the py3-none-any version. You won't lose much unless you are manipulating surface grids a lot with CAPE.

[khalils2]

is it easy to add in a feature to specify the max and min location of the lineload definition? I know this is a triload input but cape defaults to extracting the lineload on the entire component extents

[nasa-ddalle]

No, I don't think there is! I should be able to add this pretty easily, and the release of CAPE 1.2.2 should also come out shortly... It'll help with that NumPy 2.0 thing as well.