Pamela 4 into Pamela 5

models/Application_examples/Application_Process.mp

@@ -45,7 +45,8 @@
 │*│ └────────────────────────────────────────────────────┘ │
 │*│                                                        │
 │*│ ┌─[ Search Terms ]───────────────────────────────────┐ │
-│*│ │ behavior, application process; isomorphism         │ │
+│*│ │ behavior, application process; isomorphism;        │ │
+│*│ │ analysis, schedule                                 │ │
 │*│ └────────────────────────────────────────────────────┘ │
 │*│                                                        │
 │*│ ┌─[ Instructions ]───────────────────────────────────┐ │

models/Application_examples/Autonomous_Car.mp

@@ -19,8 +19,8 @@
 │*│ │ technology. It applies COORDINATE statements to    │ │
 │*│ │ add dependencies between the events within the     │ │
 │*│ │ roots "Car" and "User". Without the COORDINATE     │ │
-│*│ │ statements, the event tracesproduce invalid or     │ │
-│*│ │ erroneous combinations of events fromdifferent     │ │
+│*│ │ statements, the event traces produce invalid or    │ │
+│*│ │ erroneous combinations of events from different    │ │
 │*│ │ roots, such as the car behaving as if it had       │ │
 │*│ │ arrived at its destination when in fact it had     │ │
 │*│ │ not.                                               │ │
@@ -35,7 +35,7 @@
 │*│                                                        │
 │*│ ┌─[ Search Terms ]───────────────────────────────────┐ │
 │*│ │ behavior, autonomous car; autonomous;              │ │
-│*│ │ failure mode analysis; coordination, event         │ │
+│*│ │ analysis, failure mode; coordination, event        │ │
 │*│ └────────────────────────────────────────────────────┘ │
 │*│                                                        │
 │*│ ┌─[ Instructions ]───────────────────────────────────┐ │

models/Application_examples/Dining_Philosophers.mp

@@ -15,7 +15,7 @@
 │*│ ┌─[ Description ]────────────────────────────────────┐ │
 │*│ │ This model demonstrates using COORDINATE, ENSURE,  │ │
 │*│ │ and IF statements to come up with an answer to a   │ │
-│*│ │ problem oftenused to illustrate synchronization    │ │
+│*│ │ problem often used to illustrate synchronization   │ │
 │*│ │ issues. The logic and problem solving potential of │ │
 │*│ │ Monterey Phoenix is shown through its ability to   │ │
 │*│ │ come up with the exhaustive number of solutions to │ │

models/Application_examples/FindAdvisor.mp

@@ -16,7 +16,7 @@
 │*│ │ terms of possible decisions they could make. This  │ │
 │*│ │ example models the process of a student finding an │ │
 │*│ │ advisor for a potentially MP-related research      │ │
-│*│ │ topic. To do so, it uses rootevents, composite     │ │
+│*│ │ topic. To do so, it uses root events, composite    │ │
 │*│ │ events, atomic events, "or" logic ( ... | ... ),   │ │
 │*│ │ and COORDINATE statements. Users should inspect    │ │
 │*│ │ this model when considering the process of finding │ │

models/Application_examples/Manufacturing_Process.mp

@@ -17,8 +17,8 @@
 │*│ ┌─[ Description ]────────────────────────────────────┐ │
 │*│ │ This model demonstrates a cost analysis application│ │ 
 │*│ │ of Monterey Phoenix modeling to a manufacturing    │ │ 
-│*│ │ process.  This model was originally composed using │ │ 
-│*│ │ Eagle6, a prototype MP user interface.  Eagle6 did │ │ 
+│*│ │ process. This model was originally composed using  │ │ 
+│*│ │ Eagle6, a prototype MP user interface. Eagle6 did  │ │ 
 │*│ │ not implement COORDINATE statements, probabilities,│ │ 
 │*│ │ or event attributes so the original model used     │ │
 │*│ │ SHARE ALL to simulate COORDINATE and performed cost│ │ 
@@ -36,7 +36,7 @@
 │*│                                                        │
 │*│ ┌─[ Search Terms ]───────────────────────────────────┐ │
 │*│ │ behavior, manufacturing process; analysis, cost;   │ │ 
-│*│ │ reports, local; reports, global                    │ │
+│*│ │ report, local; report, global                      │ │
 │*│ └────────────────────────────────────────────────────┘ │
 │*│                                                        │
 │*│ ┌─[ Instructions ]───────────────────────────────────┐ │

models/Application_examples/Martian_Lander.mp

@@ -70,7 +70,7 @@
 │*│ │                                                    │ │
 │*│ │ In summary, this model demonstrates the use of     │ │
 │*│ │ COORDINATE statements to model the relationships   │ │
-│*│ │ of landing eventsand make those events easier to   │ │
+│*│ │ of landing events and make those events easier to  │ │
 │*│ │ understand using charts and "comments" from SAY    │ │
 │*│ │ statements. Users can reference this model for     │ │
 │*│ │ advice on COORDINATE statements and using MP to    │ │

models/Application_examples/Supply_Chain_with_Two_Cyber_Threats.mp

@@ -80,7 +80,7 @@
 │*│ │ behavior, supply chain; coordination, event;       │ │
 │*│ │ cyber threat; cyber-attack;                        │ │
 │*│ │ event attribute, number; table; trace annotation;  │ │
-│*│ │ risk score; risk analysis; SAY statement;          │ │
+│*│ │ risk score; analysis, risk; SAY statement;         │ │
 │*│ │ MARK command; report, global                       │ │
 │*│ └────────────────────────────────────────────────────┘ │
 │*│                                                        │

models/Application_examples/Swarm_Search_and_Track.mp

@@ -23,7 +23,7 @@
 │*│ │ UAVs. The bingo fuel condition was modeled as an   │ │
 │*│ │ optional event, in which case a UAV has just       │ │
 │*│ │ enough fuel remaining to safely return to the      │ │
-│*│ │ desired landing site. Among thetraces produced     │ │
+│*│ │ desired landing site. Among the traces produced    │ │
 │*│ │ there is one particularly questionable scenario in │ │
 │*│ │ which a UAV reached the bingo fuel condition and   │ │
 │*│ │ then began to track a target. Several possible     │ │

models/Application_examples/Swarm_UAV.mp

@@ -28,7 +28,7 @@
 │*│ │ multiple unmanned aerial vehicles (UAVs) with      │ │
 │*│ │ identical behavior in preflight, launch, ingress,  │ │
 │*│ │ egress and recovery phases. The "Perform_Mission"  │ │
-│*│ │ event isabstract; see the Swarm_Search_and_Track   │ │
+│*│ │ event is abstract; see the Swarm_Search_and_Track  │ │
 │*│ │ model in the Application_examples folder for an    │ │
 │*│ │ elaboration on an example mission.                 │ │
 │*│ └────────────────────────────────────────────────────┘ │

models/Example19_StackBehavior_BayesianProbabilityCalculationsType2.mp

@@ -26,7 +26,7 @@
 │*│ │ constrained to pop only if push occurs before it?" │ │
 │*│ │                                                    │ │
 │*│ │ When run on Firebird, the output also shows Type 1 │ │
-│*│ │ trace probability (p=nnnn on the right scroll bar, │ │
+│*│ │ trace probability (p=nnnn on the right scroll bar),│ │
 │*│ │ which will be different from the calculated Type 2 │ │
 │*│ │ values. This difference is owed to the fact that   │ │
 │*│ │ Type 1 assumes that probability of selecting an    │ │

models/Example35_Authentication_SystemReuse.mp

@@ -59,8 +59,8 @@
 │*│ │ Run for Scopes 1 and up. Viewing of traces also    │ │
 │*│ │ includes a "Swim Lanes" option. At Scope 3 and     │ │
 │*│ │ above, the attempts_exhausted event can be seen.   │ │
-│*│ │ You may hide the Requestor node in the event trace │ │
-│*│ │ graph, since the User will copy all Requestor's    │ │
+│*│ │ You may hide the Requester node in the event trace │ │
+│*│ │ graph, since the User will copy all Requester's    │ │
 │*│ │ behavior.                                          │ │
 │*│ ├─[ Run Statistics ]─────────────────────────────────┤ │
 │*│ │ Scope 1: 3 traces in less than 1 sec.              │ │