In a better world you have a csv file with temperatures (or incoming data?) of all nodes
33.5
32.4
33.9
...
and load the csv (you get an array a1) and then have one function (A) that for loops over the data.
I calculate these temperatures every timestep in Processing by calling a function.
In the for loop you would call a 2nd short function (B) to calculate the temperature just for one node. Then store this back into a 2nd array a2.
Chrisir
Are the formulae you get from Matlab set in stone and the only difference being the input data?
This is what Processing’s reference says about Java’s keyword static:
When a field is declared w/ that keyword, it means Java creates it once only, no matter how many times we instantiate its class.
Thus it is said such a field is shareable, b/c its value is the same across all instances of its class.
But the coolest thing about static is that any member of a class declared w/ that can be accessed directly w/o needing to create an instance of its class 1st!
However, considering a Processing sketch is never instantiated more than once (unless we hackishly force our hand to do it), declaring its fields and methods w/ static is moot; and we can safely remove such declaration if we prefer so.
I only do it as a way to document that such PApplet members (apart from nested classes) are stateless rather than any practical effect on the code.
This is what Processing’s reference says about Java’s keyword final:
When used on fields, local variables & parameters, it permanently seals the 1st value assigned to them.
But in this particular sketch of yours, final is also crucial to shorten the memory used by method calculateT1(). 
If we remove the 2nd keyword final declaration from where the pow() float fields are, the sketch still compiles & runs fine. 
However, if we dare removing the 1st final declaration from the original float fields, we’ve got the compilation error back: 
The code of method calculateT1(float, float) is exceeding the 65535 bytes limit.
Seems like the 2nd batch of float fields isn’t used as much as the 1st 1 to the point of exceeding the limit. 
BtW, I always try to stick the keyword final everywhere as long as I can get away w/ it. 
Actually, when I had already replaced about 4 or 5 pow() batch calls w/ final constants, the sketch was already able to compile & run! 
I’ve continued to replace all pow() calls w/ final float constants just for completeness’ sake. 
In short, both declaring the original float fields w/ final and replacing some of the batches of pow() calls w/ pre-calculated fields were the bare requirements in order to compile & run calculateT1(). 
But still, what kinda trick the final keyword does to the float fields which was crucial to shorten method calculateT1() barely enough? 
That trick is made outta “Constant Expressions”: 
Docs.Oracle.com/javase/specs/jls/se11/html/jls-15.html#jls-15.28
It kicks in everytime we assign a primitive or literal String to a final field, turning them into a “known compile time constant”! 
That makes the compiler replace all occurrences of such fields w/ their actual literal value across the compiled bytecode! 
That’s a rarity; b/c Java isn’t used to optimize code on compile time, but leaving them on run time. 
As an example, this final field would be a “known compile time constant”: 
final float F1s = 1;.
However this 1 wouldn’t due to method call, which isn’t a constant expression, although it’s final: 
final float F1s = cos(0);.
More on “known compile time constant” explanation stuff here: 
CodeRanch.com/t/612483/java/compile-time-constant
More precisely I’ve used CTRL+H inside Notepad2-mod:
XhmikosR.GitHub.io/notepad2-mod
I did the same to split each expression into its own line.
For that, I’ve relied on the option “Transform backslashes” so I could replace all + & - occurrences this way: +\n & -\n.
Also used CTRL+B over an open parenthesis in order to find its matching closing 1.
On a side note, JS got no problems running even your original “test.pde”.
You can see it by yourself using the “Processing Helper” tool from this site below:
ProcessingJs.org/tools/processing-helper.html
Just copy & paste your or my version there and click at the “Run” button.
It’s gonna print out: 253.0466351680599
Thanks, but how can I use multiple .pde files in that mode (ProcessingJs.org/tools/processing-helper.html)? Also, I tried installing JavaScript mode, but unfortunately not succeeded in doing so.
Take a look inside the “.html” files from these 2 sketches below:
https://github.com/GoSubRoutine/Ball-in-the-Chamber/tree/master/pjs-java
Again, the whole Pjs library link is loaded using an “.html” file:
https://github.com/GoSubRoutine/Ball-in-the-Chamber/blob/master/pjs-java/index.html
There’s no actual need to “install” anything:
GoSubRoutine.GitHub.io/Grumbo/Grumbo_Adventure_OOP
GoSubRoutine.GitHub.io/Ball-in-the-Chamber/pjs-java/
@GoToLoop , thank you for your patience with me 
If I open the .html file in Google Chrome I just see a white screen. Even if I download your files of Grumbo, it doesn’t work. Sorry, I’m new to all of this.
Edit: I tested with these files and I don’t see the cancas, only the header and paragraph:
index.html
<!DOCTYPE html>
<html>
<body>
<h1>My First Heading</h1>
<p>My first paragraph.</p>
</body>
</html>
<script defer src=https://raw.githubusercontent.com/processing-js/processing-js/v1.4.8/processing.js></script>
<canvas data-processing-sources=
"test.pde">
</canvas>
test.pde
void setup(){
size(800,400);
}
void draw(){
background(0);
stroke(200);
fill(255,0,0);
rect(100,100,100,100);
}
I only have to open the index.html in Google Chrome, right?
Thanks again,
Thomas
I haven’t followed the whole discussion but the html doesn’t look right: I think the script and the canvas should be between the </p> and the </body.
Another workaround: Chrome-allow-file-access-from-file.com
A more complete solution:
More solutions: Local server · processing/p5.js Wiki · GitHub
If these are variables maybe the best work around is to use a statistical method like GAM or an ordination method like a CCA and reduce your data to only the important variables.