Trouble assigning variable to solver output

[FieldEng]

I'm not able to assign the output of the solver to a variable.  I can do it with other examples, but it doesn't work with this expression.  What am I doing wrong?

[LucMeekes]

This is because the solution contains two ' variables'  that are unknown to the numeric processor: lbm and s.

You should tick the setting to allow units/constants in symbolics (under Calculation => calculation options), and see if that helps.

Success!
Luc

P.S. But the better way is to define mt as a function of its components and solve that:

And then you can calculate its numerical value with:

And do the same for the other two m-values.

[FieldEng]

Luc, unfortunately, this didn't work, but thanks for the tip.  I appreciate the quick reply.

-Kristan

[Werner_E]

I guess that setting the calc option to use units in symbolic calculations as explained by Luc will help (it not always does, though).

You may also consider to use the numeric (unit-aware) "root" function instead of the symbolic "solve" command. The "root" function can be used in two ways, either by providing a guess value or by providing an interval.

[FieldEng · Accepted solution]

This worked well, which I had seen in the examples, but I hadn't fully digested how to use the solver for my case.  Your suggestion made me take a second look at this and a friend help me figure out how to implement this.  I can index the element of "sol" that I need and assign that to the variable I want to use.  Thanks for the help.

[Werner_E]

That doesn't look OK to me as you have just one equation but you solve for two variables!?

[FieldEng]

Perhaps not, but my reasoning is as follows: "m_comp" is defined elsewhere in my worksheet and so defines "m_c".  But "m_t" only has the initial guess.  So even though I'm asking the solver to find "m_t" and "m_c", "m_c" can't change, correct?  It's just giving me back the value that was input.  I was using this as a bit of error-checking.  

But I take your point that I'm technically solving for two variables, but one (I think) is treated as a constant because it's value is linked to another variable outside the solve block.

Please correct me if this isn't the right way to go about this.

[Werner_E]

---

@FieldEng wrote:

Perhaps not, but my reasoning is as follows: "m_comp" is defined elsewhere in my worksheet and so defines "m_c".  But "m_t" only has the initial guess.  So even though I'm asking the solver to find "m_t" and "m_c", "m_c" can't change, correct?  It's just giving me back the value that was input.  I was using this as a bit of error-checking.  

But I take your point that I'm technically solving for two variables, but one (I think) is treated as a constant because it's value is linked to another variable outside the solve block.

Please correct me if this isn't the right way to go about this.

---

No, as soon as you have two variable names in the "Find" function, both are treated as variables subject to be changed. You assign m.c  the value of a previously defined variable, but that does not mean that these variables are now linked and married forever. It just means that m.c gets the value of the other variable and as m.c is subject to be changed, this is just its guess value.

Its up to Prime to only play around with one of the two variables and leave the other one unchanged or to change both variables to give you one of the infinite number of possible solutions.

Usually Prime seems to change only the first variable which may be the case in your example, too, but there is no guarantee for this behaviour.

If you want m.c to be constant, don't use it in the "Find" function.

In my answer above I suggested the root function instead of using a solve block simply because a solve block takes up much more space and IMHO looks quite ugly in Prime. But of course a solve block is as good a replacement for the symbolic "solve" as is the root command. Both are unit-aware.

[FieldEng]

Understood.  Thank you for the explanation.  I appreciate it.  

Your response makes perfect sense, and I incorrectly assumed that because m_c didn't change from the initial guess that the solver didn't/wouldn't modify it.  So, thanks for explaining.  I will look into the root function and try to implement that as well. 

[FieldEng]

Just following up to close this out.  I tested the root function for this simple case, and it seems to work just fine, as you said it would.  Your solution seems more elegant, and cleaner.

Thanks again.