{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":3176886,"defaultBranch":"main","name":"OpenVSP","ownerLogin":"OpenVSP","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2012-01-14T07:20:19.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/1330360?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1715730224.0","currentOid":""},"activityList":{"items":[{"before":"03b3c0907528aee9fdb71bcd923c2909c805b603","after":"7da9d8c7e7137e0680a98fdf9ace500fc2c5f323","ref":"refs/heads/main","pushedAt":"2024-05-14T23:43:44.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.39.1\n\nQuick bug fix release that helps with 3D background relative paths on\nWindows.  The fix looks correct, but if this works, it doesn't make sense\nhow the other platforms worked without this.  Oh well.\n\nBug fix:\n - Fix 3D background relative path bug.","shortMessageHtmlLink":"OpenVSP 3.39.1"}},{"before":"e5d6748751221d11b85a71505ba99eebacc8f0fd","after":"03b3c0907528aee9fdb71bcd923c2909c805b603","ref":"refs/heads/main","pushedAt":"2024-05-12T18:44:50.000Z","pushType":"push","commitsCount":55,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.39.0\n\nComing less than a month after the prior release, I thought about holding\noff on this release until there was more to go with it.  After all, this\nrelease really consists of just one feature and a handful of bug fixes.\n\nHowever, when I've shown the new feature to users, they want it released\nyesterday -- or sooner if possible.  Who am I to argue?\n\nOpenVSP (and its predecessors) have long had the ability to place a 2D\nimage as a background to be used as a guide when setting up a model.\nThis version takes that idea to the next level.  Instead of the image\nappearing as a static background, it is placed in the model such that it\ncan pan and zoom appropriately.  Likewise, there is no limit to the\nnumber of reference images that can be used.\n\nDescribing this feature doesn't succumb to the written word -- so look\nfor a video from me or Brandon in the near future.\n\nAside from that, there are a couple of bug fixes mixed in.  We're still\nworking through the aftermath of the DrawObj m_GeomChanged enforcement\nfrom a few versions back.  A CFDMesh tolerance has been tightened\nso cusped airfoils won't get smooshed.  And some continued build system\nimprovements to help with portability to more diverse platforms.\n\nWe've also updated (again) to the latest FLTK 1.4.0-pre release.  The\nFLTK dev team is on a big push to 1.4 and I'm trying to make sure there\naren't any surprises when it goes final.\n\nFeatures:\n - 3D Background images\n\nLibrary Updates:\n - Update to latest FLTK dev as they approach 1.4.0\n - Build LibXml2 with -PIC\n - Update GLEW build integration to match modern GLEW\n\nBug Fixes:\n - Move Documentation build to MacOS from Ubuntu to get latest Swig\n - Drop MacOS-11 build, move to MacOS-12\n - Use gcc-11 on MacOS for ADEPT and OMP builds\n - Fix MeshGeom DrawObj issue\n - Tighten tolerance in MatchBorderNodes - Thanks Andy.","shortMessageHtmlLink":"OpenVSP 3.39.0"}},{"before":"8972602aeef878d15a5cfcadf42ed2e3564cbc69","after":"e5d6748751221d11b85a71505ba99eebacc8f0fd","ref":"refs/heads/main","pushedAt":"2024-04-17T23:18:56.000Z","pushType":"push","commitsCount":46,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.38.0\n\nComing just a month since the last release, you won't be surprised that\nthis version is somewhat small overall.  It includes some more fixes\nthat I thought about releasing as 3.37.3.  However there is also a\nbroad variety of quality of life improvements that this release\ndeserves a .0 update.\n\nIn the Geom Browser, the Show Only, Show, and NoShow buttons now work\nlike the other things (like Hidden, Shade, Feature lines) with respect\nto applying changes recursively.  I.e. now they only recurse a collapsed\ntree.  When you Show or NoShow a parent entity on an expanded tree,\nthe visibility change only affects the selected entities.\n\nThe number of Sets is now user-adjustable.  Go to the Set Editor,\nclick the arrows at the top of the window.\n\nMeasure (probe, ruler, protractor) now works for non-surface Geoms.  This\nis mostly for blank and hinge geoms, but works in a rudimentary way\nfor Mesh and HumanGeom (it always measures from their component origin).\nSo users who use Blanks extensively as intermediate coordinate systems\ncan now use them for all their Measure needs.\n\nSeveral improvements around advanced links.  Unique variable names are\nnow enforced when renaming variables.  The variable renaming buttons\nwere re-worded for clarity.  Multi-line error messages are now displayed\nwhen links break.\n\nThe full-path filename at the bottom of the screen is now displayed\nin a larger font for better visibility on high resolution screens.\nThe filename (without a path) is now displayed in the title bar\nat the top of the screen.\n\nThe integrated flowpath engine extension has a pair of improvements.\nFirst, streamtubes are now extended to a constant X value -- even\nwhen the start of the streamtube is not at a constant X.  There is also\na new option to auto-determine the extension distance based on the\noverall dimensions of a selected Set.\n\nHeight/width/area/aspect sliders are now displayed for CEdit type\nXSec curves -- even when the detailed editing window is not displayed.\nThis should allow for quick adjustments without having to get deep\nevery time.\n\nBetter patch names are assigned to wing patches when exporting STEP\nand IGES files (Thanks Jeff V.).  This should make it easier to identify\nwing trailing edge, upper, and lower surfaces in meshing tools.\n\nThere is also now an option to merge the lower and upper trailing edge\npatches together (and leading edge too).  Some meshing tools did not\nappreciate that we output split TE patches -- so now we'll merge them.\n\nAs usual, there are a few bugfixes too -- mostly related to graphics\nglitches that were introduced in 3.37.0.\n\nI don't think there are any high risk changes in this -- and hopefully\nthe graphics glitches introduced in 3.37.0 are calming down.  Everyone\nshould update.\n\n\nFeatures:\n - Show Only, Show, NoShow buttons now recurse like everything else.\n - User adjustable number of Sets\n - Measure works with non-surface Geoms (blank and hinge)\n - Unique variable names enforced when renaming advanced link vars\n - Re-worded variable renaming buttons\n - Output multi-line error messages when links are broken\n - Bigger filename at screen bottom\n - Filename in main title bar\n - Integrated flowpath modeling extension now extends to constant X\n - Integrated flowpath modeling extension distance auto determined\n - Height/width/area/aspect sliders for CEdit XSecCurve now displayed\n - Better patch names for unintersected STEP/IGES surface export\n - TE surface merging for STEP/IGES export\n\nLibrary Updates:\n - Update to latest FLTK dev as they approach 1.4.0\n\nBug Fixes:\n - Fix invisible subsurfaces\n - Fix XSecSurf highlights that won't go away\n - Expand ranges for AR and Span - should fix some odd wings seen in Group\n - Fix some odd scattered indexing bugs\n - Fix some problems with CFDMesh sourcing","shortMessageHtmlLink":"OpenVSP 3.38.0"}},{"before":"1c2117c4933c0015c9bdce9f92b0fa98a506c3cd","after":"7b9c5dd7074b699c4c28cde1eb13bc5a94819b00","ref":"refs/heads/Fixes","pushedAt":"2024-04-08T20:29:18.000Z","pushType":"push","commitsCount":11,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"Add GUI support for merge LE/TE when exporting Un-trimmed STEP and IGES","shortMessageHtmlLink":"Add GUI support for merge LE/TE when exporting Un-trimmed STEP and IGES"}},{"before":"27e778fcea8b5d08072a0953f6fe7e67f66b43fc","after":"1c2117c4933c0015c9bdce9f92b0fa98a506c3cd","ref":"refs/heads/Fixes","pushedAt":"2024-04-05T20:37:33.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"Protect subsurfaces on invalid mainsurfindx on startup","shortMessageHtmlLink":"Protect subsurfaces on invalid mainsurfindx on startup"}},{"before":"b9c425fa5a8c8aff8d5830bad9ea9f171d56fdc5","after":"27e778fcea8b5d08072a0953f6fe7e67f66b43fc","ref":"refs/heads/Fixes","pushedAt":"2024-03-25T15:41:11.000Z","pushType":"push","commitsCount":972,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"Fix botched conditional for displaying subsurfaces.","shortMessageHtmlLink":"Fix botched conditional for displaying subsurfaces."}},{"before":"2502fac12c6fc97069948fec9678fcc074db0ef2","after":"8972602aeef878d15a5cfcadf42ed2e3564cbc69","ref":"refs/heads/main","pushedAt":"2024-03-22T23:47:38.000Z","pushType":"push","commitsCount":14,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.37.2\n\nVersion 3.37.0 had a handful of blemishes.  One lead to the release of\n3.37.1 a few days later -- and today I'm releasing 3.37.2 with a few\nmore fixes.\n\nNo new features or other big improvements here.  Just bug fixes.  So,\neveryone should update as soon as they can.\n\nThis version includes another FLTK update.  This update should make it\na tiny bit easier to build OpenVSP on some unusual computers that some\nfolks may have.\n\nFeatures\n - None\n\nLibrary updates\n - FLTK Updated to latest pre-1.4.0\n   . Eliminates -no-pie flag from build, helps with Python API on RHEL9\n\nBug fixes\n - Fix a handful of crashes in/around structures\n - Fix a handful of 3D graphics glitches","shortMessageHtmlLink":"OpenVSP 3.37.2"}},{"before":"0c4fdecd201c94bd3e715efeff3bcaf485b65191","after":"2502fac12c6fc97069948fec9678fcc074db0ef2","ref":"refs/heads/main","pushedAt":"2024-03-11T01:11:11.000Z","pushType":"push","commitsCount":4,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.37.1\n\nThis patch changes a compiler flag that makes a new dependency build\nproperly on Windows.  This in turn fixes CFDMesh and FEAMesh on Windows.\n\nWithout this change, 3.37.0 will quickly crash if you try to use either\nmesher.","shortMessageHtmlLink":"OpenVSP 3.37.1"}},{"before":"4ba939ff18997266a5d3993067948ff0b74735bf","after":"0c4fdecd201c94bd3e715efeff3bcaf485b65191","ref":"refs/heads/main","pushedAt":"2024-03-04T17:41:34.000Z","pushType":"push","commitsCount":262,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.37.0\n\nThis version is dedicated to the X-57 Maxwell.\n\nI remember the joy and excitement the team had as they watched\nAdministrator Bolden announce the program and the first piloted\nNASA X-plane designation in more than a decade.  I was in the\naudience at Aviation 2016 poised to upload the model to the Hangar\nas soon as the announcement was made.\n\nOpenVSP played at least a small part in the early stages of the\nprogram.  Fit Model was used to build the fuselage model for the\nTecnam.  Nick used OpenVSP for the configuration studies.  Jeff used\nit for the wing design.  Brandon designed the signature folding props\nand nacelles.  He went on to maintain the definitive geometry that\nwould be the basis for all the CFD studies you've seen.  There are\nother uses and users that I am regrettably leaving out.  It was an\nhonor to support their work and to have OpenVSP make a contribution.\n\nThis week, I'll join those friends and many others at the X-57\nCloseout to glean what I can from the vast learnings of this team.\nI know this didn't turn out the way you'd all hoped.  I also know\nthat you've made a big contribution to aeronautics.  You've changed\nthe design space.  You've moved the needle forward.  Congratulations\non your collective success.  Thank you for all your work.\n\n\nOnce again, this release has been a long time in the making.  There are\nonly a handful of main themes here -- and while you might not think they\napply to you, I strongly encourage everyone to upgrade.  In addition\nto some really cool advances (that you might not need), there are a ton\nof smaller improvements and fixes that will benefit everyone.\n\nSo go ahead and start your download before you finish reading this\nmessage.  I'll wait here until you come back.\n\nThomas Nascenzi & the team at M4 Engineering and I teamed up on an SBIR\nfor the Navy starting a bit over two years ago.  While lots of smaller\nfeatures from this effort have already been released, this release\nmarks a milestone in this project -- the general release of what was\noriginally the 'big ask'.  Don't worry, there will be a lot more\nprogress from this project to share in the future, but this is an\nexciting development for everyone involved.\n\nThe Navy uses a couple conceptual design tools (ADAPT and AIDEN)\nthat can use OpenVSP as a geometry engine.  They talk to OpenVSP\nthrough the Python API.  These tools have a GUI front-end that the user\nspends most of their time with.  The Navy wanted to be able to have\nthe OpenVSP GUI open and interactive at the same time as their other\naircraft design tool's GUI was open and actively manipulating the OpenVSP\nmodel.  Change something in ADAPT, see the change in OpenVSP and\nvice versa.\n\nThis may seem straightforward, but there is a lot of magic that has to\nhappen for this to work.  Making it work took a lot of Python magic as\nwell as a lot of C++.  Thomas and I worked together on this -- with\nThomas handling all the Python (and the good ideas) and me supporting\nwith whatever was needed on the C++ side.\n\nSo, you can now have an OpenVSP GUI open and interactive while your\ncustom Python application pounds away.  At a minimum, you'll be able\nto visualize and interact with a 3D model of your concept as your\noptimization study progresses.  I have no doubt that users will come\nup with many more applications for this capability.\n\nOf course, having a fully-featured OpenVSP GUI open while another\nprogram is manipulating the model may seem like running with flaming\nscissors.  It might be.  To address this, we've added some\n'parental control' API routines.  These calls allow you to disable\ncertain features and capabilities in the OpenVSP GUI.  For example,\nyou can Nerf the OpenVSP GUI to a view-only interface for a\nmodel.  We'll see how this works out in practice and if more is needed.\n\nWe've moved the API documentation from being specified where things\nare registered in AngelScript to their native C++ home.  This also\nallows us to generate a parallel set of Python documentation for\nthe API.  Going forward, the OpenVSP website will host both Python\nand C++ / AngelScript documentation for the API.  The Python docs\nare also now included in the openvsp package and should be available\nin your IDE when you're using OpenVSP.\n\nAmong all of this work, there are some small changes to the Python\nAPI.  It should be pretty harmless and generally more Pythonic, but it\nmight cause API users a few headaches.\n\nOne of the C++ changes to support using the GUI from Python affects\nhow 3D objects are updated to the graphics card.  We now attempt to\nupdate these objects less frequently.  This should also provide a nice\nperformance boost, but at the risk of losing things once in a while.\nIf you find that something vanishes where it was previously visible,\nmention it on the Google Group.\n\n\n\nNext, some bad news.  In addition to lots of good stuff, 3.33.0 also\nincluded some lousy regressions.  These regressions made FEAMesh and\nCFDMesh both slow and crashy.\n\nIf you aren't into sausage making, skip a few paragraphs...\n\n   The performance regression was super subtle.  The regression was\n   actually over in Code-Eli (50487cc2bbfe).  Notice how I nonchalantly\n   say \"This does mean that a copy of the surfaces must be made because\n   they are no longer const.\".  Yep, that was it right there.  I even\n   knew I was doing it at the time.\n\n   Something I did to improve the accuracy and reliability of a\n   surface-surface intersection algorithm inadvertently caused us\n   to copy and destroy a giant complex data structure a bazillion times.\n   All the time was spent allocating and releasing memory.\n\n   The fix (c53f910aa2e4) was to allow a shift to be incorporated into\n   the surface evaluation on-the-fly and switching back to a const\n   reference.\n\n\n   The crash-causing regression was something else entirely.  When\n   our mesher (CFD or FEA) generates an initial mesh (InitMesh), it\n   transforms every surface patch into flat 2D space and generates\n   the initial mesh there.\n\n   You might be wondering why you can't just use the surface's U,V\n   parametric coordinates for generating the initial mesh.\n   Unfortunately, a square in U,V is not guaranteed to look anything\n   like a square on the surface.  The closer we can get to flattening\n   the surface without distortion, the better.\n\n   For years, we've used an algorithm based on Mysticism and Voodoo\n   to map surfaces from U,V to 2D space.  It generally worked, but it\n   was a dark place that will make you see things that aren't there.\n\n   In our next regression (47e5744550eb), I tried to replace the\n   old approach with something I thought would be an improvement.\n   Spoiler alert, it broke things.  In particular, it would distort\n   surfaces near degeneracies in a way that fine meshes would turn\n   out hosed.\n\n   As it turns out, this flattening problem is something that computer\n   graphics researchers have been working on for years, so it made\n   sense to drop the custom code and use an off-the-shelf solution\n   instead (OpenABF).  It does a great job and should provide all\n   the benefits I was hoping to achieve when I 'upgraded' the\n   algorithm earlier.\n\n\nThe good news is, not only are these regressions fixed in this version,\nI spent a bunch of time profiling FEAMesh under some extreme use\ncases (thanks James Joseph) which revealed some unexpected slowdowns.\nI was able to re-write several algorithms providing dramatic speedups.\n\nIf you previously grew tired of wondering how long ConnectBorderEdges,\nBuildFeaMesh, and BuildChains could possibly take, you'll like what\nyou see here.  In addition to these three, a bunch of other speedups\nwere made across the meshing workflow.\n\nWhile I was in there, I was able to fix a bunch of bugs in and around\nFEAMesh.  Most of these were reported by users - thanks James & Bryan.\n\n\nThe other big item you'll notice in this release is we finally have\nfull Apple Silicon M1/M2 processor support.  The holdup had been our\nscripting language - AngelScript.  AngelScript does some low level\nstuff such that it includes some assembly code that needs to know\nexactly how compilers on a given operating system and processor\nplatform send data to a subroutine.  This includes things like\ndo you pass arguments LtoR or RtoL, how many registers there are,\nhow do you use the registers, what do you do when you run out of\nregisters, etc.  The main AngelScript author doesn't have an Apple\nSilicon machine and has had to rely on others to do this work\n(which is outside my range).  Someone finally came along to make\nit work, so here we are.  I helped track down one bug that turned\nup along the way.\n\nSo, if you've purchased a Mac in the last three and a half years or so,\nyou'll want to check out the new download option.  It should be faster\nfor you, but everything else should be the same.\n\n\nYou may have noticed that there are a bunch of library updates along\nthe way.  In addition, there are a bunch of updates to the CMake build\nsystem.  If you build OpenVSP yourself, you'll probably want to blow\naway your build directories and start over.  Sorry for the hassle.  If\nyou typically use -DVSP_USE_SYSTEM_FLTK=TRUE (likely for Linux users),\nI suggest you don't do that now.  The FLTK project is about to release\nversion 1.4.0 and I've bundled a cutting edge version here.  It includes\nmany improvements that won't be available in a system-installed package\nuntil the final release happens and then the Linux distributions update\nto it and then your machine is updated too.  Just use the one I bundle,\nyou'll get the latest.\n\n\nBeyond that, there are a good number of small fixes and features tossed\nin.  As mentioned earlier, everyone should update.  It is the right thing\nto do.\n\nFeatures:\n - OpenVSP GUI available from Python API\n - Facade allows OpenVSP API to run transparently on separate process\n - GUI parental controls\n - Python API documentation\n - Surface Intersecion, CFDMesh, and FEAmesh much faster\n - Add surface names to Intersect, CFDMesh, and FEAMesh progress output\n - Native Apple M1/M2 support\n\nLibrary Updates:\n - New AngelScript - full M1 support\n - Removed local modifications to AngelScript for documentation\n - Moved AngelScript build to Libraries, better CMake integration\n - Updated FLTK to 1.4.0-preview version\n - Updated FLTK integration to Modern CMake\n - Added OpenABF - Angle Based Flattening\n - Updates to Code-Eli, performance improvements for meshing\n - Update how Eigen is included in project\n\nBug Fixes:\n - Fix meshing performance regression from 3.33.0\n - Fix meshing crash regression from 3.33.0\n - Fix on-the-fly updating of meshing lengths with model unit scale\n - Fix not scaling fixed points with model scale\n - Fix not scaling trim planes with model scale (thanks Bryan)\n - Fix FEA crash with subsurfaces and trims (thanks Bryan)\n - Fix FEA crash with empty trim part (thanks James)\n - Fix corruption of Quad Meshes\n - Fix FEA Individualize Rib and Plane routines (thanks James)\n - Fix scroll wheel zoom on Windows\n - Fix Wing insert section update from API.\n - Fix error in K to F unit conversion (thanks sladesladeslade)\n - Fix VSP icon in Ubuntu (thanks Cibin)","shortMessageHtmlLink":"OpenVSP 3.37.0"}},{"before":"c011578175da93a5f03cb490b1518c6f91bf439d","after":"4ba939ff18997266a5d3993067948ff0b74735bf","ref":"refs/heads/main","pushedAt":"2023-10-28T05:11:49.000Z","pushType":"push","commitsCount":203,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.36.0\n\nIt has been almost three months since the last release.  Tons of\nwork has been going on, but mostly on a big change that still isn't\nquite ready yet.  While I have been focused on the big stuff, a ton of\nother features and fixes have accumulated.  In fact, some of them are\npretty big in their own right.  So clearly we're past due for a release.\n\nIf you compile OpenVSP yourself (particularly on antiquated platforms),\nupdating to this version is going to be painful for you.  One of the\nlibraries I need for the next round of changes requires we move\nto C++17 (we've been on C++11).  In turn, that requires that we move\nto CMake 3.24 (we previously only required 3.1).  These changes cause\na nightmarish ripple through the toolchain continuum.  I'm sorry.\n\nI've stopped builing and packaging for Python 3.6, moving support to\nPython 3.9 and 3.11.\n\nYou can now choose to use your operating system's native file open/save\ndialog window instead of OpenVSP's custom one.  Go to File... Preferences...\nand make the change.  You will lose access to your list of favorite\nfolders, but it will act like most every other program on your computer.\n\nThere are many improvements to the user experience around advanced links.\nYou can now sort advanced link variables.  Variable names can be generated\nautomatically.  Unique names are suggested when you try to use conflicting\nnames.  You can rename a variable and the code will be updated too.\nAdvanced link actions are now available from the API.\n\nWhen a circular link loop update is stopped, a warning message is issued.\n\nA spanwise fraction 'eta' coordinate has been introduced for wings.  This\nis available for specifying control surfaces, attachment to wings, and\nconformal components based on wings.  This should be more natural than\nU, R, and L for wings.\n\nA protractor angle measure has been added to the Ruler and Probe measure.\nIt can be used to measure and mark angles and projected angles.\n\nA classical lamination theory (CLT) calculator for composite materials\nhas been added.  Now you can build up a ply schedule in OpenVSP for your\nstructures.\n\nStructures can also now include off-body fixed points.  These can be used\nto build connections or to apply boundary conditions and loads.  Unlike\non-body fixed points, these float in space outside of the FEM mesh.\n\nSeveral structures tweaks were provided by Bryan S.\n\nThere are lots of bug fixes all around.  Lots of help from users finding\nand tracking them down.\n\nTwo bugs were fixed that caused long-running API cases to have heavy\nmemory growth.  If you still encounter memory-growth please help out with\na test case so I can get it fixed.\n\nA subtle problem with IGES and STEP files was fixed.  Many downstream\nprograms didn't seem to care, but perhaps this will improve interoperability\nfor some of you.\n\nOpenVSP should work on Apple Silicon again (still via Rosetta2).\n\nFeatures:\n\n - Native file dialog\n - Advanced Link UI improvements\n   .Sorting variables in link\n   .Suggest when conflicting name used\n   .Automatic naming\n   .Variable renaming w/ code search\n   .Advanced Link API\n - Issue warning message when a link loop is stopped\n - Protractor measure\n - Wing eta coordinate for control surface, attach, and conformal\n - Classical laminate theory for materials specification\n - Off-body fixed points for FEA Mesh\n - Write template NASTRAN executive and case control sections\n - Change NASTRAN files to use RBE2 instead of RBAR1\n - Improved error message when OpenGL will not load\n - Various cleanups to build system\n - Build Pyhton 3.9/3.11 instead of 3.6/3.9\n\nLibraries:\n - Pinocchio moved to Libraries\n - Update Pinocchio to C++17 version\n - Update Clipper1 to Clipper2, move to Libraries\n - Update Delabella\n\nBug fixes:\n - Fix knot values in STEP and IGES files\n - Improve greying-out of 4-digit CLi parameters for prop\n - Improve adherence to 6-series airfoil nomenclature\n - Fix memory leak and growth plaguing long-running API users\n - Fix order of Calculix dependent/independent connected nodes\n - Fix planar slicing behavior with just one slice","shortMessageHtmlLink":"OpenVSP 3.36.0"}},{"before":"3d2356bdc1fd59c0470bde868cd55d87ea26769c","after":"c011578175da93a5f03cb490b1518c6f91bf439d","ref":"refs/heads/main","pushedAt":"2023-08-02T05:04:10.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.35.3\n\nDisable feature that is causing problems with CFD and FEA Mesh before\nthe Workshop.","shortMessageHtmlLink":"OpenVSP 3.35.3"}},{"before":"eb2112f8f1b88c2b3f28249fe15bd8b6d751a800","after":"3d2356bdc1fd59c0470bde868cd55d87ea26769c","ref":"refs/heads/main","pushedAt":"2023-07-29T00:32:23.000Z","pushType":"push","commitsCount":6,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.35.2\n\nQuick fix to prevent inf and nan values from propagating to delabella\nwhere they can cause a crash.\n\nThese inf values likely come from the tri-tri intersection code.  Fixing\nthem there would be preferable, but this remains a reasonable safeguard.","shortMessageHtmlLink":"OpenVSP 3.35.2"}},{"before":"671dc56e4e0d37bcde844a18c8759d7c6416bc7b","after":"eb2112f8f1b88c2b3f28249fe15bd8b6d751a800","ref":"refs/heads/main","pushedAt":"2023-07-27T06:53:45.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.35.1\n\nQuick fix to help DegenGeom and VSPAERO thin surface work with\nchanges to Mass Prop.","shortMessageHtmlLink":"OpenVSP 3.35.1"}},{"before":"7253c6dd8c42e135558089598974b13bf112b5bf","after":"671dc56e4e0d37bcde844a18c8759d7c6416bc7b","ref":"refs/heads/main","pushedAt":"2023-07-24T20:20:59.000Z","pushType":"push","commitsCount":81,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.35.0\n\nThis release is a little modest, but there is still enough here to\nwarrant a release before the Workshop.  I'm looking forward to seeing\nsome of you in two weeks -- unfortunately, if you aren't registered,\nthe registration is full.\n\nThe most user-visible change here is an update to the Mass Properties\ncapabilities.  Before, only a Blank component could be assigned a\npoint-mass value (and only a mass, no inertias).  With this update,\nany component can be assigned mass properties -- including mass, local cg,\nand inertias for the component.  (What do you call a point-mass with\nnon-zero inertia?)\n\nThese component mass properties will be included with the overall mass\nproperties calculation along with the volume-based and wetted area-based\ncalculations already performed.\n\nExisting files with point-mass assigned to Blanks will be converted to the\nnew system -- this is not a backwards compatible change.\n\nBlank components can now have symmetry (like all other components).  That\nway, you can easily add a symmetrical copy of a Blank's mass properties.\n\nThe under-the-hood mass properties calculations have had some small changes\nthat should slightly increase accuracy (in ways that nobody will really\ncare about, but that make me happy.)\n\nMost of the rest of the changes are very much behind-the-scenes.\n\nSome API calls have been added to enable creating/deleting User Parms\nfrom the API.\n\nOpenVSP's PMARC 12 file writing was slightly improved and some Python\nscripts for working with PMARC input/output files are now included.\n\nThe ability to read an existing VSPAERO run from disk was added to the\nAnalysis Manager -- exposing it to the API.\n\nThe biggest under the hood change should be invisible to users (except\nfor hopefully fewer crashes).  I've begun replacing a fundamental\nlibrary with an alternative.  The old library has a great reputation\n(and we've used it forever), but when things go bad, it does not fail\ngracefully -- it crashes the entire program.  This new library seems\nrobust and reliable so far -- but I'm hoping that if there are problems,\nit will fail much more gracefully.\n\nYou will mainly see this difference in CompGeom and friends.  If this\ngoes well, we will later also switch to this new library in CFDMesh and\nFEAMesh.  It isn't quite ready for that yet.\n\nThere were a few improvements contributed from the community.\n\nThanks Cibin Joseph for a bug fix when writing Degen Geom files.\n\nThanks to Jeff Allen for making it possible to delete multiple parameter\nlinks at one time -- making the Add-All buttons much more useful.\n\nAll that and a few bug fixes here and there.\n\nIf you can't make Oshkosh this week, download a new OpenVSP and make\nyourself an airplane.\n\nFeatures:\n - Specified mass properties extended to all components\n - Point masses can now have inertia specified\n - Blanks can now be assigned symmetry properties\n - User Parm management added to API\n - pyPMARC added to python package\n\nLibraries:\n - Use Delabella CDT library for CompGeom & friends\n\nBug fixes:\n - Fix missing fields in DegenGeom file.\n - Fix halfmesh bug for VLM with vspgeom files to vspaero.  Thanks Tim.","shortMessageHtmlLink":"OpenVSP 3.35.0"}},{"before":"984bb67f84d29b55b97eb7324b60fcbe6d24b360","after":"7253c6dd8c42e135558089598974b13bf112b5bf","ref":"refs/heads/main","pushedAt":"2023-06-05T16:54:13.241Z","pushType":"push","commitsCount":82,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.34.0\n\nAlthough I've been furiously working on lots of things, I hadn't planned\non making a release because I didn't think I had enough stuff ready. I\nstepped back and took another look and realized that most of the in-work\nstuff was actually ready and only one big thing (that won't be ready for\na while) was not.  So here is a pile of stuff for everyone to enjoy.\n\nIt was previously very challenging to get satisfactory results from\nV-trimming of conformal components.  This was partially due to inherently\ncomplex behavior -- but was exacerbated by terrible default settings.\nDefault values for V-trimming have been improved, hopefully making the\nexisting capability more usable.  In addition, a simplified Side 1,2,3,4\napproach to V-trimming has been introduced.\n\nIn addition to simplifying V-trimming, the V-parameter speed of a\ntrimmed surface used to be very non-uniform.  This erratic behavior made\nfeatures like UV attachment to trimmed conformal components impossible.\nIt also made subsequent analysis of conformal components more difficult.\n\nThis behavior has been fixed.  The V-parameter speed of a trimmed\nconformal component is uniform and the V-origin does not shift.  The\nV-parameter of un-trimmed portions of the component remain unchanged.\nThis improvement has a perhaps unexpected effect -- end capping is now\nsupported for conformal components with U trimming.  Most significantly,\nthis means a trimmed conformal component can now have a rounded end.\n\nJason Welstead had contributed some improvements and cleanups to the\nCHARM Automation Python tools.  While these are relatively minor changes,\nthis serves as proof of concept for navigating the NASA release process.\nLook for more updates to come from Jason.\n\nThe primary meshing controls for CFDMesh and FEAMesh have been augmented\nwith non-dimensional alternatives.  The maximum edge length can now be\nspecified as a fraction of model size (as determined by the bounding box\ndiagonal).  The minimum edge length and maximum gap can now be specified\nas a fraction of the maximum edge length.  These changes should make it\neasier to get to an initial reasonable mesh and to better build intuition\nin the meshing parameters.\n\nCFDMesh and FEAMesh have been augmented with visualization of the local\nmesh edge length criteria.  Mesh parameters are determined by the\ninteraction of multiple criteria -- it is not always obvious which\ncriteria determines the edge length at any particular location.  This\nnew visualization mode illustrates the active criteria and should make\nadjusting meshing parameters more intuitive.\n\nThe under-development adjoint version of VSPAERO has been ported to\nWindows (it was previously only available on Mac and Linux).  Now that\nit is available on all platforms, the developers will be able to start\nmaking its capabilities generally available.\n\nU-direction clustering control has been added to fuselage and stack\ncomponents.  This can be used to tailor the wireframe mesh representation\nor to compensate for a distorted mesh caused by skinning.\n\nLimits on end-cap tessellation requirements have been relaxed.  Before,\nonly odd values greater than or equal to three were possible.  Now, both\neven and odd values greater than or equal to two are possible.  This\nwill allow finer control of mesh resolution and also allow coarser\nrepresentations of end caps and trailing edges.\n\nWhile technically a bug fix, one fix is significant enough to almost be\nconsidered a feature.  OpenVSP has long behaved erratically when more\nthan one chord value of a given wing were updated at the same time.\nAlthough this is impossible through normal interactive use, this occurs\ncommonly when automating some sort of design process via Design Variable\nsupport or the API.  Various incantations have been tried in the past,\nmost involving frequent calls to Update() -- severely slowing any\ndesign process that involves changes to the wing chord.  This issue has\nbeen fixed -- or at least an official workaround is now supported.\n\nIf you need to change wing section chords from a design process, use the\nfollowing recipe:\n\n1) Set all wing section drivers to root-chord, tip-chord, span.\n2) Use the tip-chord to set every chord value possible.\n3) Use the root-chord of the first wing segment to control the root chord\n     of the entire wing.\n\nThis recipe should work and will only require a single call to Update()\nafter all Parms have been set.  Let me know if you have any trouble\nwith this.\n\nThere are a few small bug fixes in this release, but this one was\ndominated by new features.  Download and enjoy.\n\nFeatures\n - Improved V-trimming defaults for conformal components\n - Side 1,2,3,4 V-trimming for conformal components.\n - Improved skinning of V-trimmed conformal components.\n - End caps for U-trimmed conformal components.\n - Improvements to CHARM automation scripts (thanks Jason Welstead)\n - Non-dimensional CFD/FEA Mesh controls\n - Visualization of CFD/FEA Mesh criteria\n - Windows support for VSPAERO adjoint version\n - U-direction clustering control for Fuse and Stack\n - Relaxed limits on end-cap tessellation\n\nFixes\n - Setting multiple chord values in design context.","shortMessageHtmlLink":"OpenVSP 3.34.0"}},{"before":"989207da17e2c916b19827640371c4187f5975ce","after":"984bb67f84d29b55b97eb7324b60fcbe6d24b360","ref":"refs/heads/main","pushedAt":"2023-05-01T03:17:06.000Z","pushType":"push","commitsCount":2,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.33.1\n\nFix problem attempting to calculate RST/LMN attachment parameters to\nparents that don't have surfaces - and therefore don't have these\ncoordinates defined.","shortMessageHtmlLink":"OpenVSP 3.33.1"}},{"before":"a219a79f0d0d1cd701ebf986f978a0f12dbd1107","after":"989207da17e2c916b19827640371c4187f5975ce","ref":"refs/heads/main","pushedAt":"2023-04-29T00:30:30.000Z","pushType":"push","commitsCount":76,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.33.0\n\nEarlier this year, the world lost a brilliant light far before its time.\nAlex Stoll was a kind and gentle soul, a visionary aircraft designer, and\na good friend.  Alex committed his career to eVTOL far before it was a\nthing -- he helped create the revolution.  Thank you for everything you\nbrought to the world.  This version is for you Alex.\n\n\nA lot of recent development time has gone into long term work that isn't\nready for release yet.  However, this release includes some cool features\nand a stack of good bug fixes.  Everyone should update\n\nThe often imitated wing tip-cap feature introduced in OpenVSP 3.6.0\nprovided a simple way to create rounded (and other) wing tip treatments.\nInstead of wrestling with CAD, you got what you wanted with just a few\nclicks.  Since then, I've spent a lot of time looking at airplane wingtips.\nIn that time, I've noticed that the rounded tips of 3.6.0 don't quite\nmatch how many aircraft do it.  This version introduces a new\nextended tip cap type that should better match some of these cases.\n\nThis change had some unexpected ripple effects.  The new tip caps are\nconstructed with a challenging surface topology.  OpenVSP's mesher had\nto be improved to handle them robustly -- and those changes should\nimprove meshing for all shapes.\n\nOpenVSP's parent-child attachment is used to simplify building complex\nmodels by allowing the designer to express intent instead of values\nin positioning.  This version adds two new coordinate systems that\ncan be used to define attachment.\n\nThe RST coordinate system is a volumetric coordinate system defined within\nan object.  This is perfect for packaging studies -- where you're working\nto place all the stuff you need inside the aircraft.\n\nThe LMN coordinate system is like RST -- but instead of varying with\nparameter speed, LMN is linear in arc-length along the RST directions.\nUse RST if you want to position something on the third bulkhead.  Use LMN\nif you want to position it one third of the way along the fuselage.\n\nRST coordinates had previously been exposed via the API for some users\ndoing cool structural MDO work.  Take note, the S coordinate has been\nredefined to be double what it was before.  Before, it existed in the\nrange [0, 0.5] -- now it exists in [0, 1.0].  If you stored old S values\nand you need to use them with a new version, just multiply by two.\n\nFinally, 'dimensional' forms of the U, R, and L coordinate can now be used\nto specify attachment.  This should make it easier to achieve certain\nresults (attach to the third bulkhead) without doing any pesky algebra.\n\nIn addition to those features, there are some VSPAERO updates (mostly\nfixes) and a stack of general fixes.  This includes patching a few\nmemory holes that users had found -- if you're still seeing memory leak,\nreach out and we can work on building a better test case.\n\nIf you're in doubt, you need this version.  Download it now.\n\n\nFeatures\n - New extended tip-cap geometry\n - Convert CFDMesh 2D mapping to arclength based mapping.\n - Handle potential no-volume corners in CFDMesh.\n - RST and LMN Attachment\n - RST S re-defined.\n - Dimensional U,R,L attachment.\n - Visualize wake edges on vspgeom export.\n\nFixes\n - Clean up behavior of pull-down menus with special characters\n - Fix remaining issues from snprintf conversion\n - Fix syntax errors in master aero V&V script\n - Fix some quad-mesh bugs in FEAMesh.  Hopefully fixes needle meshes.\n - Make beam elements obey trim zones in FEA Structure generation.\n - Expand height of ExportScreen\n - Fix memory leaks from CreateParm() being called.\n - Fix memory leak in MeshGeom::Flatten...\n - Fix wake identification.\n - Handful of VSPAERO fixes.\n - Silence VSPAERO viewer checks for VSP_NO_GRAPHICS build\n - Silence cgx/ccx not found errors on Windows\n - Fix MeshGeom not scaling on load problem.","shortMessageHtmlLink":"OpenVSP 3.33.0"}},{"before":"e2502ce4a767ac59c40675fa0abced28f8356046","after":"a219a79f0d0d1cd701ebf986f978a0f12dbd1107","ref":"refs/heads/main","pushedAt":"2023-03-22T18:43:34.000Z","pushType":"push","commitsCount":33,"pusher":{"login":"ramcdona","name":"Rob McDonald","path":"/ramcdona","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/1329600?s=80&v=4"},"commit":{"message":"OpenVSP 3.32.2\n\nWhile 3.32.1 fixed the most egregious issues with 3.32.0, it was still\na bit of a hot mess in its own right.  This release helps tame the chaos,\nhopefully it gets people back on track.\n\nOf course, I couldn't help myself and stick to _just_ bug fixes.  So,\nif you use CFDMesh & Co, you will find that the 'f' and 'r' keys work\nlike they do in the rest of OpenVSP.  These are UX candy -- go ahead\nand indulge.\n\n(For those of you that are wondering what pressing 'f' or 'r' does --\ntry it!  If you can't try it right now, pressing 'f' will 'f'it all the\nvisible stuff onto the screen by auto zoom, pan, and setting the center\nof rotation.  Pressing 'r' presents a bunch of green points.  Click one\nand it will be set to the center of rotation and moved to the center of\nthe screen.\n\nOther than that, it should mostly be a bunch of fixes.  The migration\nfrom sprintf to snprintf broke a few things.  Those have been fixed and\nan audit has been conducted, so hopefully we're through with that.\n\nFix lingering problems with CompGeom half meshes and tag files.  Previous\nfixes broke things like Wave Drag and Parasite Drag.\n\nFix error validating subsurface structures properties on structures\ndata transfer.  Was preventing analysis of structures with subsurfaces.\nImprove error messages while we're at it.\n\nAttempt to set property length unit when converting an old file.\nUnfortunately, I can't see a way to convert\n\nSome of the VSPAERO output files were updated, our parsing of those files\nhas now been updated to match.\n\nFix some small VSPAERO issues that were causing hangs and crashes when\nslicing planes were active.\n\nOverall, not a ton of stuff -- but everyone should update because the\nproblems these fixes address were hitting a bunch of users.  Hopefully\nwe'll keep things under control for a while going forward.\n\nFeatures\n - Make 'f' and 'r' keys work with CFDMesh & Co.\n - Allow parasite drag to use a reference wing not in the active Set.\n - Print missing command line when calling CpSlicer.\n - Clean up mesh from repeated mass properties analysis.\n - Attempt to set property length on import of older structures files.\n\nFixes\n - Fix validating structures subsurfaces\n - Fix visual artifacts in orthotropic material GUI in structures.\n - Fix double fee in Cartesian plotting library that shows up with bleeding\n   edge versions of FLTK.\n - Fix parsing of VSPAERO output files.\n - Fix wave drag, parasite drag, half mesh, tag files issue.\n - Fix snprintf conversion issues\n - Silence snprintf warnings\n - Fix VSPAERO with slicing planes active","shortMessageHtmlLink":"OpenVSP 3.32.2"}}],"hasNextPage":false,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAESf3WGwA","startCursor":null,"endCursor":null}},"title":"Activity · OpenVSP/OpenVSP"}