Proper way to use adaptivity

[DRoam]

I could really use some help with the proper way(s) to use adaptivity.

I've used Inventor for literally thousands of hours, but using adaptivity for even the simplest of applications always, always, always results in broken assemblies when I try to use it. It might work at first, but once I make just the wrong change to my assembly, suddenly two or three parts which adapted fine before decide not to adapt, and I end up with several sick constraints. Even a Rebuild All will not repair the assembly.

In its simplest form, this is all I want to do:

I want to constrain one end of a part (such as a steel member) to one face, and constrain the other end to another face, and have the member change its length if the distance between the two faces changes.

That's it.

I could spend a couple hours describing all the ways I've tried to do this, but the short and sweet is that I'm very careful not to create unsolvable adaptivity situations. I always build my parts and constrain them so that there is one and only one correct "solution" to the constraints.

So, I'd like to hear the ways you all use adaptivity that work. Any tried-and-true methods would be greatly, greatly appreciated. Thanks in advance.

[rhasell]

Hi

If I understand adaptivity correctly it is not really there for ongoing design changes, it more suited as a helper tool. (I base this on previous posts of using adapitivity to design a part, then to switch it off when you are done. It might just be because it adds overhead to the system)

If you have a lot of changes happening, I find the most robust method is to use some sort of skeleton model, and or a master part/s.

Even the simplest of things can be used.

e.g. The distance between the two faces could be as simple as one dimension derived to the respective part, this will update without fail, every time. (Granted, the entire assembly needs to have a connect to the master part in some form or another)

I personally use adaptivity very seldom, as I reuse a lot of parts and assemblies, which I just cannot get my head around the intricacies of the various reference’s.

[PaulMunford]

Could you use frame generator?

[Anonymous]

If I understand correctly what you're trying to do, one alternative could be to create the part in the assembly itself with the "Create" button on the assembly ribbon. Then use copy object on the two pieces you want to attach to, and import them into the part file itself as construction surfaces. then model the part from there, using those surfaces to define the part. For instance, you might start an extrude sketch on one face, and use "To" as the termination option and select the other surface. As the referenced objects in the assembly move, their construction surface representations in the part file move with them.

[DRoam]

@rhasell: Thanks for the response!

---

@rhasell wrote:

If I understand adaptivity correctly it is not really there for ongoing design changes, it more suited as a helper tool. (I base this on previous posts of using adapitivity to design a part, then to switch it off when you are done. It might just be because it adds overhead to the system)

---

That's the answer I was afraid of, and I'll be very disappointed in Inventor and Autodesk if it turns out to be the case. I can understand the difficulty with an assembly with lots of complex adaptive relationships with multiple adaptive DOFs per part, but for a part to be able to change its length should be one of the most basic and obvious capabilities for a 3D modeling software. Adaptivity should be the answer, and a simple one at that.

---

@rhasell wrote:

If you have a lot of changes happening, I find the most robust method is to use some sort of skeleton model, and or a master part/s

---

I often do use skeletal modeling, but sometimes that just won't work. Skeletal modeling really only works for basic frames. It shouldn't be necessary anyway, especially when I only have 4-5 members that need to have an adaptable length.

---

@rhasell wrote:

The distance between the two faces could be as simple as one dimension derived to the respective part.

---

This is definitely the simplest solution but it only works if the faces in question are constrained to each other, which is rarely the case. Usually the positions of the two faces in space are determined by other constraints on thier respective parts, and not by the relative position of the two parts.

Thanks a lot for the input. Not trying to shoot down your responses, they're all valid, just not a viable solution for our needs in the majority of cases.

[DRoam]

@PaulMunford:

---

@PaulMunford wrote:
Could you use frame generator?

---

Unfortunately, we rarely are actually dealing with a pure structural frame. It's usually a custom assembly made of plate, sheet metal, purchased parts, etc., and we just need several structural members spanning certain places for support. Also, we often need certain plates in an assembly to have an adaptive length. Either way, not a viable use for frame generator. But thanks for the suggestion!

[DRoam]

---

@Anonymous wrote:

... Then use copy object on the two pieces you want to attach to, and import them into the part file itself as construction surfaces. then model the part from there...

---

That's an intreguing suggestion, I wasn't even aware of the Copy Object command. I've never used that before, but I just did a quick experiment with it and it definitely looks like a possible solution.

It's very similar to another workflow I've used where I use the "Create Simplified Part" command on the assembly to create an associative multi-body part version of my assembly, and then Derive that "assembly part" into the part that needs to be adaptive. Similar to your suggestion, I can then use the relevant assembly faces directly in the modeling of the adaptive part. Along with the issue of an extra file to keep track of, the big issue with this is that the adaptive part "contains" my assembly, so I can't place it directly into the assembly. I have to instead create a parent assembly and place the main assembly and adaptive part into it. This gets complicated fast, but it's extremely robust because it doesn't rely on Adaptivity.

The workflow I just described lacks the biggest weakness of Adaptivity, which is that Inventor has no way to know which side of the relationship is driving and which side is driven. I think this is the cause of 90% of the issues with Adaptivity. What makes the workflow I described so robust is that the assembly itself is an independent animal which doesn't care at all about the adaptive part. The assembly tells the adaptive part what to do, via the associated Simplified Part version, but the adaptive part has no reciprocating connection to the assembly. This is not the case with Adaptivity. With Adaptivity, there's a constraint between the assembly and the part. The assembly should be the "driving" side, and the part should be the "driven" side--but Inventor doesn't know this. For all it knows, the length of the part should tell the assembly components where to go, rather than vice versa. As a result, the solution process is more complicated and open-ended, and I think this why Adaptivity has so many issues. If we could designate certain constraints as "Adaptivity-driving" constraints, which only tell a part how to adapt and don't try to affect the assembly, I think Adaptivity would be much more robust.

The point of writing that book was twofold: to communicate the most robust way I've found to have an adaptive part, in case someone else wants to use it, and to say that the workflow you've suggested, Rusty_Shackleford, could potentially have the same strengths as the workflow I've used, minus the file-manangement and assembly hierarchy weaknesses. I'll have to do some experimenting before I know for sure.

All that said... thanks! 😉

[rhasell]

Interesting topic.

Been burning the candle at both ends, so my brain not working too well.  I use adaptivity quite successfully via the "Copy Object" method.

[blair]

Adaptivity is great to copy geometry from one part onto another part. Such as creating a gasket that will mate to a flange. Project the flange geometry and extrude the gasket.

I clear Adaptivity as soon as possible. First it add additional system load and your model loads and runs slower. The worst is the instability that enters the model. The more items you have Adaptive, the more problems that can be introduced into your model. You model can be pushed and pulled in directions you didn't think possible by adding a constraint from one object to another.

A little bit of Adaptivity is good, a lot of Adaptivity is bad.

[Anonymous]

---

@Anonymous wrote:

Adaptivity is great to copy geometry from one part onto another part. Such as creating a gasket that will mate to a flange. Project the flange geometry and extrude the gasket.

I clear Adaptivity as soon as possible. First it add additional system load and your model loads and runs slower. The worst is the instability that enters the model. The more items you have Adaptive, the more problems that can be introduced into your model. You model can be pushed and pulled in directions you didn't think possible by adding a constraint from one object to another.

A little bit of Adaptivity is good, a lot of Adaptivity is bad.

---

I have slowly come to the same realization and do the same thing.

I do have a question though, if you use copy-design how do you track the adaptive parts if there is changes in the new design?

I saw the OP's post and agreed that yes making the length of an extuded part should be the simplest thing in the world in this kind of software but I have found to my dismay that it is something that is unworkable in Inventor.

[blair]

I don't let Adaptivity go beyond the initial design state. When my design is finalized, all Adaptivity is cleared. I only use it to cross project geometry from one part to another and then clear the Adaptivity as soon as possible.

I learnt my lessons a long time ago (12-14 years ago) with too much Adaptivity.

[DRoam]

---

@DRoam wrote:

---

@Anonymous wrote:

... Then use copy object on the two pieces you want to attach to, and import them into the part file itself as construction surfaces. then model the part from there...

---

...the workflow you've suggested, Rusty_Shackleford, could potentially have the same strengths as the workflow I've used, minus the file-manangement and assembly hierarchy weaknesses. I'll have to do some experimenting before I know for sure.

---

Almost a year later, I can confirm that the answer to this question is yes. The Copy Object tool is potentially the most robust way to use Adaptivity. The reason is just as I said--it's a one-way street. The Assembly sends its geometry into the Adaptive part and the Adaptive part uses that geometry. But there are no constraints involved in this, so the Part in no way tries to affect the Assembly. One-way street = no solving issues.

Just one problem. The Copy Object tool is bugged.

It works fantastic at first. Whenever I've used it, after I get it all properly set up to drive certain features in my Adaptive part, it works great. Moving the driving component(s) in my Assembly results in an immediate update to the related features in my Adaptive part. But after I move on and continue adding to my assembly, somewhere down the road I move one of the driving components, and the "Copy Object"-ed features in my Adaptive part just sit there. They don't update. Clicking the "Update" button does nothing, and even a "Rebuild All" does nothing.

I submitted a couple of assemblies doing this to Autodesk and they confirmed it as a bug. It's being looked into, but no word on if/when this will be addressed.

So there goes the most "robust" way to use Adaptivity down the drain.

Which takes us back to traditional, constraint-driven Adaptivity:

---

DRoam wrote (slightly modified):

The biggest weakness of Adaptivity is that Inventor has no way to know which side of the relationship is driving and which side is driven. I think this is the cause of 90% of the issues with Adaptivity. With Adaptivity, there's a constraint between the assembly and the part. The assembly should be the "driving" side, and the part should be the "driven" side--but Inventor doesn't know this. For all it knows, the length of the part should tell the assembly components where to go, rather than the location of the assembly components telling the part how long to be. As a result, the solution process is more complicated and open-ended, and I think this why Adaptivity has so many issues. If we could designate certain constraints as "Adaptivity-driving" constraints, which only tell a part how to adapt and don't try to affect the assembly, I think Adaptivity would be much more robust.

---

I still stand steadfast by this statement. The way I see it, there are three primary defects with adaptivity:

Defect 1: The two-way relationship when using constraint-driven Adaptivity (i.e. the inability to specify the driving/driven direction)

(Defect 1-a: The inability to make a Shared Sketch adaptive, or to define a consumed Sketch as Adaptive without also making the consuming feature (e.g. Extrusion) also adaptive. More on this below.)

Defect 2: The occasional non-associative "bug" when using 'projected geometry'-driven Adaptivity (see this thread and this Idea)

Defect 3: The lost association bug when using "Copy Object" Adaptivity

So we have three different ways to use Adaptivity and all three of them have a glaring defect which makes them useless for anything past "helping" with the initial design, which I really couldn't care less about. I don't need a cute tool to help me get my design right in the initial stage--I can do that well enough myself. What I need Adaptivity for is keeping up with the relative position of all of my associated features as the design progresses and changes.

Adaptivity should be capable of doing this, and it would be if those three defects were addressed.

I use Adaptivity very strategically. I follow three rules to ensure that I'm making robust, single-solution assemblies:

1. In Adaptive parts, ensure that every sketch and every feature is fully defined EXCEPT for in the degree(s) of freedom that need to adapt. Also make sure that ONLY the sketch(es)/feature(s) that need to adapt are made Adaptive.
2. In the Assembly, ensure that the location of every part is fully defined, and do so using constraints which are only applied to fully-defined part features, not adaptive ones.
3. In the assembly, after fully defining part positions, apply constraints as necessary to drive Adaptive features in a Part. But when doing so, always ensure that the driving side of that constraint is to a feature which is fully defined and not adaptive.

If these rules are followed, then there is only one solution to the location of each part, and there is also only one solution to the location/size of the Adaptive features inside of those parts.

(Side note: Following these rules is sometimes made difficult thanks to Defect 1-a described above. This limitation means that in my Assembly, I can't apply any constraints to said Extrusion to define the part's position. Because if I did, those constraints might try to adapt the Extrusion rather than define the part's position. ... Again, partially thanks to Defect 1 rearing its head.)

This kind of strategic, single-solution Adaptivity should be able to endure throughout the entire design process. The only reasons it can't are the three defects I listed above.

Sorry for such as long post--but if I have to write "the book" on Adaptivity to help Autodesk understand why Adaptivity is such a weak and underperforming feature, so be it.

Autodesk, Adaptivity is a weak and underperforming feature. Sometimes to the point of being useless and causing more harm than help. I've just given a detailed diagnosis of why (at least from a logical standpoint--you guys get the fun task of addressing it from a programming standpoint ). Please, please fix those defects so that we can take advantage of Adaptivity's untapped potential. (Attn: @johnsonshiue, @rangt)

[johnsonshiue]

Hi!

Let me reply to the 4 defects you listed here.

Defect 1: The two-way relationship when using constraint-driven Adaptivity (i.e. the inability to specify the driving/driven direction)
[JS]: Adaptivity is largely based on assembly constraint between two components. Assembly constraint is always bi-directional. This is done purposely for performance reason. Also, for most of the constraining relationship, there may not be a dedicated driver. In adaptive relationship, however, there is clear definition of adaptor and adaptee.

(Defect 1-a: The inability to make a Shared Sketch adaptive, or to define a consumed Sketch as Adaptive without also making the consuming feature (e.g. Extrusion) also adaptive. More on this below.)
[JS]: This is a limitation established early on. The objective was to stablize adaptive solve and to avoid one adaptor to drive mutliple adaptive features within a part. We have discussed about the possibility of removing the restriction. The conclusion is that there is no technical reason it should be blocked. We are trying to see how we can remove the block.

Defect 2: The occasional non-associative "bug" when using 'projected geometry'-driven Adaptivity (see this thread and this Idea)
[JS]: It does sound like a bug. But, I need to see a repeatable example. If there is prior defect ID, please let me know.

Defect 3: The lost association bug when using "Copy Object" Adaptivity

[JS]: We are aware of this defect. This is specific to Copy Object -> Surface selection. If the entire body is selected, the bad behavior would not happen. We are trying to find a solution.

As you indicated earlier, Adaptive is a powerful tool. The idea is simple: basically geometry on CompA can be driven by geometry on CompB. To certain degree, it is like exposing the DOF of geometry at part level to assembly level. What is not easily understood is that such relationship exists only within the assembly where CompA is adaptive to CompB, not anywhere else. However, the geometric deformation on CompA will carry forward to whichever assembly it exists.

Some users believe that adaptive CompA can have one shape in one assembly and have another shape in another assembly. This is false. So far, Inventor part can only have one geometric definition at a time, regardless of where it exists.

Aside for the defects, Inventor did not provide tools helping user manage adaptive relationship. On 2017, Inventor provide Relationship command at part level showing the feature dependency. Also the name of component contributing to adaptive geometry is shown in the browser. These help users understand the relationship better. Hopefully, it will be better managed.

Over the years, I have seen cases that an adaptor component is also an adaptee component or a derived part is an adaptor or adaptee. I personally do not believe these are good modeling practice. The complicated and cyclic relationship can be hard to understand and it will cause trouble down the road.
Adaptive relationship needs to be actively managed and understood. When it is used, make sure document it clearly in engineering note or in color code. When there is design change, make sure adaptive relationship is reasonable and understandable (who drives whom). We are working on improving this area. In the meatime, if you encounter any unreasonable behavior, please let me know asap.

Many thanks!

[DRoam]

Thanks for the prompt and detailed reply, @johnsonshiue!

Let me respond to some of your informative comments.

Defect 1:

[JS]: Adaptivity is largely based on assembly constraint between two components. Assembly constraint is always bi-directional. This is done purposely for performance reason. Also, for most of the constraining relationship, there may not be a dedicated driver. In adaptive relationship, however, there is clear definition of adaptor and adaptee.

I agree with this paragraph 100%. Basically what you just described are two types of constraints: assembly constraints and adaptivity constraints. As you said, one type of constraint (the Assembly type) is bi-directional and does not usually have a dedicated driver/drivee. And the other type of constraint (the Adaptivity type) does have a clear definition of adaptor and adaptee (or driver/drivee).

And as this is the case, wouldn't the assembly be more robust if we could TELL Inventor when a constraint is meant for Adaptivity and not for assembly, and also TELL it which direction that driving relationship goes? My belief is that it would.

There's also a second big advantage to having dedicated adaptivity constraints, which I'll get to shortly.

Defect 1-a

[JS]: ... The conclusion is that there is no technical reason it should be blocked. We are trying to see how we can remove the block.

This is great to hear, I really hope this is addressed soon.

Defect 2

[JS]: It does sound like a bug. But, I need to see a repeatable example. If there is prior defect ID, please let me know.

Totally understandable. I'm trying to come up with a repeatable sample assembly. 

(I'm adding in a very important defect I didn't mention, related to 'projected geometry'-type adaptivity):

Defect 2-a: With 'projected geometry'-type adaptivity, for whatever reason, after we create the adaptive relationship, the adaptive relationship "constrains" the source part and recipient together along the DOFs included in the adaptive "relationship". Even though the Adaptive relationship should be adaptive and not driving, it still constrains them and they can't be moved relative to each other, unless and actual constraint is created to define their position along the DOFs "constrained" by the Adaptivity.

This is in contrast to Adaptivity created using "Copy Object", which works like it should: even after creating the adaptive relationship, it lets you free-drag the source and recipient as you want, and then immediately updates the recipient after the free-drag is done. I see no reason why 'projected geometry'-driven Adaptivity shouldn't be capable of this as well, since it's essentially the same thing except it uses projected sketch geometry rather than "copied" geometry. There's no constraint between the source geometry and the sketch, so there's no reason we shouldn't be able to free-drag either part and then have the Adaptive sketch immediately update, the same way "Copy Object"-ed geometry does.

This leads me to my second point regarding Defect 1. Another advantage to Adaptivity-specific Constraints is that, now that Inventor knows they're for Adaptivity, it doesn't have to force their specified relationship while a free-drag is taking place. Just like with Copy Object adaptivity (and with what I'm proposing for projected geometry-adaptivity), the Adaptive relationship would "relax" while a free-drag is taking place and then immediately re-solve once the free-drag is done. This, of course, is not possible with traditional Assembly constraints--they have to be, and should be, respected all the time including during free-dragging. Which is a problem when they're used to drive Adaptive features, because Adaptive relationships can and should relax while a free-drag is taking place. And dedicated Adaptivity constraints would make this possible.

Basically, you can sum up Defects 1 and 2-a like this: Adaptive relationships should be relaxed relationships. That means two things: 1) They should relax during free-dragging and should not act as a constraint, and 2) They should always solve LAST during an assembly solve (after all parts have been positioned correctly) so that they impose the correct final geometry on Adaptive parts. Would you agree with this statement? If so, then it is necessary to allow us to specify when a constraint is for an adaptive relationship, as well as to address Defect 2-a.

Defect 3:

[JS]: We are aware of this defect. ... We are trying to find a solution.

Also great to hear! Again, I hope this is addressed soon.

[JS]: This is specific to Copy Object -> Surface selection. If the entire body is selected, the bad behavior would not happen.

That's good to know! I wasn't aware of that. The Autodesk agent I was working with on this issue didn't mention that. I'll have to see if I can change my workflow to take advantage of this. Thanks for that information.

Other comments:

I do understand the Adaptivity fundamentals you described. I understand that there is an exclusive relationship between the adaptor and adaptee, and that relationship needs to be managed. I model with the awareness that a single part file cannot be made Adaptive in more than one context and then expected to take on a different form in each context; if I want to accomplish this effect, I have to create a separate part file for each context. It would be fantastic if we could combine iPart and Adaptivity functionality to accomplish this, but that's a whole different ballgame and something to tackle down the road.

[JS]: Over the years, I have seen cases that an adaptor component is also an adaptee component... I personally do not believe these are good modeling practice. The complicated and cyclic relationship can be hard to understand and it will cause trouble down the road.

I do agree that making an Adaptive part also be an Adaptor (driver) could lead to a cyclical relationship and cause trouble. However, this is far less likely to happen if Defect 1 is addressed and we're allowed to define the direction of an Adaptivity-driving constraint. It is possible to build a cyclic relationship between Adaptive parts which is unsolvable or has more than one solution. But it's also possible to strategically build this relationship so there is one and only one solution, which can be found if the driving/driven direction is known. Whatever the case, this workflow (using an Adaptee as an Adaptor) is currently allowed, so we can take advantage of it if we want, which is nice. I like that this potentially hazardous workflow is left up to the user to decide if and how to use. In my opinion that's how it should be.

Again, thanks for your detailed reply. Fortunately, I think the only things in this post that require your response are my comments on Defect 1 and Defect 2-a. Any additional comments you have are welcome as well. Thanks!

[smokes2998]

adaptivity if you understand the logic of top down modelling works great but; many user who don't under stand the logic try and use to to speed up the design process and end up shoot themselves in the foot with it.

[johnsonshiue]

Hi! Regarding #1, I checked with our developer and got better understanding. Actually, although constraints are bi-directional, the way they are solved for adaptivity does have the concept of master and slave. Adaptive geometry is allowed to deform and it would be the slave being driven by assembly constraints. Certainly, there might be defective cases, which will need to be further investigated. If you can send me a case exhibiting the behavior, I can help take a look. About #2.a, projected sketch locks up DOF, this is a design choice to keep sketch stable. When the adaptive part has its own DOF, other lines constrained to the projected sketch will have to react to additional DOF. This can easily lead to sick sketches or failed features. Indeed, this behavior is specific to adaptive sketch. Copy Object does not have the same restriction. It is because Copy Object directly references the source body geometry and usually, source body geometry is stable by the time it is being referenced. Many thanks!

[andrewdroth]

The proper way to use adaptivity is to NEVER use it.

It just doesn't work. 

I've had Autodesk trainers try and tell me it's the best thing since sliced bread, but what you need to understand is these peoples models don't need to perform in a real world environment. If it unstable that is fine because it's just for show.

Use multi-body parts. 

Create bodies for each part in an assembly.

Use the sketches (not the feature edges!) to form the parts you want to 'Adapt'

Keep all your features below your sketches and workplanes in your browser using the EOP marker as you model.

If you model in this manner you can create very complex, robust, and parametric models that only require one part to be modified in the event of a design change.

Autodesk should be teaching the multibody approach and ditching anything adaptive.

[Anonymous]

Man, what a debbie downer, they just got adaptivity working and now we're going to throw the baby out with the bathwater.

Why not just tell us to go to fusion while you're at it.... or just do it in CAD!

[DRoam]

@johnsonshiue, thanks again for your response and for looking into this.

To respond, I have to return to this statement: Adaptive relationships should be relaxed relationships. They should not be constraining relationships.

The slave part in an Adaptive relationship should not restrict the motion of the master part. It just doesn't make sense, and there's no reason for it. And this behavior is very confusing to Inventor users because it is illogical.

The fact is, even though both constraint-driven and projected geometry-driven Adaptivity restrict degrees of freedom and REQUIRE additional assembly constraints to update them, this is not logical or necessary.

I'll explain why I say this.

Explanation:

Spoiler

================================

Let me address constraint-driven adaptivity first.

1. With respect to Adaptive parts, there are two types of constraints: Those applied to fixed geometry on the Adaptive part (to "hold it still", i.e. define its position), and those applied to adaptive geometry on the Adaptive part (to "stretch" it, i.e. define its shape). I'll call the constraints applied to fixed geometry "positioning" constraints, and those applied to adaptive geometry "stretching" constraints.
2. In an assembly with Adaptive parts, while we're doing an Update and the assembly is being solved, if Inventor tries to apply a stretching constraint on AdaptivePartA before ALL of the positioning constraints have been applied, the resulting shape for AdaptivePartA will be incorrect because it will have adapted based on the position of parts which aren't correctly positioned yet. As a result, when Inventor goes to apply the respective positioning constraint on AdaptivePartA (which is applied to fixed geometry and therefore cannot adapt the part), there will be a relationship conflict between the positioning and stretching constraints. In light of this, the solve process should always resolve all positioning constraints first, and then resolve all stretching constraints.
3. In an assembly with Adaptive parts, constraints applied to fixed geometry (positioning constraints) should be enforced at ALL times, including during a free-drag (just as constraints are now). However, constraints applied to adaptive geometry (stretching constraints), if they're enforced during a free-drag, will actually PREVENT the changes to which they're supposed to adapt! In light of this, stretching constraints should not enforce themselves during a free-drag. Once the free-drag is complete, the assembly should then update and solve all relationships as normal.

In regards to number 2, I don't currently have on hand an example of an adaptive assembly which says there are conflicting relationships even though it should solve, but I have seen this many times before (hence the reason I don't have an example--I stopped using Adaptivity, like most users). If I can find or make one, I will certainly post it. I wouldn't be surprised if there is a formidable pool of Adaptivity support cases where users have submitted dysfunctional Adaptive assemblies, some of which would demonstrate the flaw in solving order that I've described. Even if Inventor does have some automated master/slave identification, I can guarantee this is not as foolproof OR as fast as the calculations would be if the designer could specify the intent of each constraint rather than the software trying to guess it with each solve.

In regards to number 3, yes, it is possible to free-drag a part to a location where the "stretching" constraints which were allowed to relax subsequently can't be resolved--but it's already possible to CONSTRAIN a part into a location where those constraints can't be resolved! So "stability" is not a reason to restrict us from free-dragging parts, because the same solving calculations will take place whether we free-drag a part and let it go, or we apply additional constraints to move it. After all, as I described, all of the positioning constraints will still stay enforced during free-dragging, so it's not like we can free-drag to a location which conflicts with the positioning constraints. And then once the part is where we want it, the stretching (Adaptivity-driving) constraints will kick in and do their thing to adapt the geometry of parts as necessary. The free-drag restriction is a fabricated restriction, and Inventor could be programmed so that we can free-drag parts with the positioning constraints enforced but stretching constraints relaxed, and then once the part is released, solve to satisfy both the positioning constraints and stretching constraints as normal.

So I've just demonstrated that it's logical and even necessary (for proper and un-restricted functionality) for intended "stretching" constraints to be relaxed relationships--to relax during free-dragging and not act as a constraint, and to always solve LAST during an assembly solve. This is necessary if not for stability, then for improved calculation time; and if not for improved calculation time, then at least to avoid unnecessarily restricting free-drag functionality.

================================

Now for projected geometry-driven Adaptivity.

This one is much simpler. Basically, just like with constraint-driven Adaptivity, we are currently required to use constraints to adjust a part's position if geometry has been projected to/from that part. This is unnecessary, because the same problems (sick sketches and failed features) which might occur from free-dragging that part to a bad location could also occur from constraining the part to a bad location. So the restricted DOF's are completely unnecessary. Besides, there should be absolutely no bi-directional relationship between the source and recipient of the projected geometry in the first place; the Adaptive sketch on the recipient should be the ONLY feature which cares about the relationship between the two parts, and it should only do so passively by responding to changes to the source, not actively by forcing the source part to stay where it is. 

So now I've also demonstrated that it's logical and even necessary, for proper and un-restricted functionality, for projected geometry-relationships to be relaxed relationships--to relax during free-dragging and not act as a constraint, and to only try to update AFTER all constraints have been resolved.

================================

So logically, there's no reason for the free-dragging restrictions. There may be some current hurdles in the programming which make removing those restrictions difficult, which is understandable--but logically, it is possible, and indeed it's how it should be.

Also, I see no reason, logically or from a programming standpoint, not to provide the additional control and stability of signaling to Inventor that a constraint is a stretching constraint (not a positioning constraint) and indicating which direction the master/slave relationship should go.

As I said before, the slave part in an Adaptive relationship should not restrict the motion of the master part. It just doesn't make sense, there's no reason for it, and this behavior is very confusing to Inventor users because it is illogical.

It's time to address these issues with Adaptivity so that it can finally deliver on its potential and behave as expected. It's time for Adaptivity to finally meet the expectations of the professionals who have, time after time, turned their back on it because it doesn't behave like it logically should. Professionals including myself, andrewdroth, blair, Mario428, rhassell, tsreagen, wimann, karthur1, DVDM... and that's just a few that I found with a quick search.

[CamPhoenix]

Its 2024 and this in depth conversation regarding adaptivity and its flaws are still not fixed or enhanced. What a shame that Autodesk has been aware of this particular features flaws and we are still dealing with this problem.  It is the most detailed discussion I have come across with users that clearly understand what is going on.  Hope more power users keep this thread alive so maybe we can nudge Autodesk to address this once and for all or at least show some signs of attempts to improve it or just remove it in upcoming patches or releases. Discouraging users to not use this or telling users they know not what they do when the feature is clearly lacking is not acceptable people.