As an aerospace engineer who codes rather than a software engineer, is there a cheatsheet that talks about how to use git from a "when do I commit/merge/etc" rather than a "this the command to perform commit/merge/etc"? Basically, an "Idiot's Guide to Making My Life Easier with Git"
I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.
> While my answer seems logically just as good to explain this stuff.
It sounds logical if you don't have a background in aerospace, but otherwise it's relatively inaccurate. For example:
> So far my best guess is that it's related to landing gear. Landing gear makes significant portion of the total weight
Landing gear makes up roughly 3% of the total takeoff weight. Hardly significant compared to fuel and cargo/passengers. [1]
> you want to keep it short and compact.
This is certainly true from a structural standpoint.
> Engines are the heaviest things in passenger planes, so landing gear is close to engines.
Compared to a person, yes. Compared to the total cargo/passengers, not really. The 787 MGTOW is ~500,000, of that, the two GE GEnx-1B engines weight about 26,000 lb combined.
The landing gear is "close to the engines" in your example picture, but this is because you typically place the main landing gear such that it is near the center of gravity. The nose gear only supports 8-15% [2] of the aircraft weight to make steering possible while taxiing. Some commercial aircraft have tail mounted engines such as the MD-80 (https://upload.wikimedia.org/wikipedia/commons/2/25/Allegian...). The wing (and landing gear) are indeed further aft since the CG is moved back further due to the engine placement.
In addition, comparing the number of wheels is a red herring for a commercial jet v. a cargo plane. The CG location relative to the wheelbase will be remarkably similar in both cases. However, military cargo planes often operate out of poor and/or shorter airfields. This limits the amount of weight you can put on each wheel if you're landing on asphalt rather than reinforced concrete, so you have more wheels with less load per wheel to keep from sinking into the ground. In addition, more wheels allows you to slow down quicker since you can spread out the braking action.
> With cargo plane the heaviest part of the plane is the cargo.
The cargo/passengers are a significant portion for commercial transports as well. Again for the 787, you've got around 100,000 in cargo/passengers (about 20% mass fraction). The C-17 carries 170,000 lbs of cargo with a 585,000 MGTOW giving a mass fraction of 29%. Not too surprising they have a higher mass fraction there since they're not adding any parasitic mass for things like passenger comfort.
lotsoffactors' comments on cargo loading/unloading considerations and the U-2 being a mid-wing aircraft are correct as well.
Sources: Aerospace Engineer and Raymer's Aircraft Design textbook (basically the bible of aircraft design).
[1] Chapter 15 of Aircraft Design: A Conceptual Approach (3rd Edition) by Daniel Raymer
Because his answers are accurate. While weight and aerodynamic performance are very important, aircraft design is inherently multi-disciplinary and requires tradeoffs depending on the design requirements.
No, the forces are transferred to the fuselage in any case. If they weren't, the wing wouldn't be bending relative to the cabin, it would just experience rigid body motion instead.
The article's explanation is a bit simplified. It sounds like his explanation is more akin to a body freedom flutter response where the aircraft's short-period mode is coupled to the structural response. What he observed is probably closer to a more classical flutter response with the wing's bending and torsion coupled. A gust hits the wing, which increases the load, this increases the bending deformation which can also induce torsion causing a twist in the wing. At too high of a speed (the flutter speed), the response is unstable and can quickly become catastrophic. At normal speeds, the oscillation will tend to die out as the restoring force of the structure and the damping from the structure, aerodynamic loads and controls causes the response to die out. Interestingly, you can go past the first flutter speed of an aircraft with a properly designed control system (aeroservoelasticity) meaning you can get away with a lighter (read, more flexible) wing structure.
Why MATLAB? If you're looking to optimize, that's the opposite direction I'd be going. Numba, Cython or writing C or Fortran if you really need the speed is where you should be going imo.
I'm surprised he didn't mention the volumetric efficiency of compressed hydrogen compared to gasoline when comparing the specific energy density of the two fuels. Yes, you have more than 3x the energy per unit mass, but you have more than 5.5x less energy per unit volume. So instead of a simple 12 gallon gas tank, you need a 66+ gallon pressure vessel adding plenty of weight and taking up volume that would otherwise be useful for cargo or other purposes.
Your requirements are from the perspective of people who view/use the code. I'd argue there are many benefits for the coder by releasing code including getting feedback from the community on aspects that could be improved or changed. This learning aspect is important as well
Hypersonic flight environments are very, very difficult to replicate in wind tunnels. We can replicate portions of the environment, but due to the highly coupled nature of the responses seen by flight vehicles at these speeds, there's always a tradeoff. To really understand what's going on, you need high enthalpy, high pressure, high Mach number flow for a reasonably long period of time. Experimental scaling is only so helpful depending on what you're trying to investigate. For a fully coupled response, you basically end up with a scaling ratio of 1 since the different physics clash when trying to scale the many parameters you need to achieve similarity. Realistically, flight test is the only way to truly get the conditions and response you need, but that's very expensive and risky and you can't build a huge factor of safety into the vehicle or it won't be able to meet the needed performance. Instead, we use a combination of simulation tools and targeted experiments to try and reduce the risk/cost for flight tests.
Vanguard target date retirement fund. Auto-invest set and forget. Maybe once I have more I'll do a 3-fund portfolio to reduce the expenses a bit. Returns should generally track the market, pretty much hold until retirement.
So LaTeX sucks, but there's not a good alternative?
I'm in the midst of creating a document from scratch with LaTeX for the first time (as opposed to using a template provided to me) and while some things have been annoying, it's mostly been the learning curve of figuring how to do what I wanted. Tables are a mess though. It seems like I need to stitch 3 different packages together to do what I want with my tables.
> If we add up all the value of the survivors, maybe we come to the conclusion that there was no bubble?
Factoring in inflation would that still be true? Do the internet companies make up a significant percentage of the stock market like they did in 2000? Is this comparison even valid since I'd expect the tech/internet sector to have grown significantly as the internet has matured since 2000?
That's probably your best bet. I know with Abaqus, you could potentially do that with the python scripting, but a lot of the stuff I've done creates a model with a python script, writes a dummy input file with nodes, element connectivity and set definitions, then I read that into MATLAB and write out a reorganized/more readable input deck from there. If I refine the mesh, I just rerun the MATLAB script and it spits out the new input file. If your model is complicated, another way you could do it is create multiple node/surface/element sets for each boundary condition and then just update the BC keyword section with the proper set and constraint. The benefit there is that you can manually tweak and remesh the model in the GUI and then set it off running with the shell script, but without needing to explicitly track node numbers since they're store d in the sets. That might be a bit overcomplicated though if your model is simple enough or the node numbering is consistent enough to keep track of.
I haven't used Calculix, but I was under the impression it uses an Abaqus format input deck? Looking at the documentation, this appears to be the case.
.jpg){kind=link}
I've tried to use git a few times at work, but I always end up forgetting to use it for awhile when deadlines start creeping up so it becomes "well, the code works in it's current state and it's been 2 months since I committed, so I should probably update the repo" which doesn't seem much better than periodically backing up the folder.