A method and system for faster-than-real-time predictive computational fluid modelling of various phenomena within a digital twin.

Abstract

Creating a Faster Than Real Time (FTRT) predictive model for indoor air quality (IAQ) and fire within a digital twin, comprising creating a number of baseline IAQ models and baseline fire models which

Description

In accordance with a first aspect of the invention there is provided a computer-implemented method for Faster-Than-Real-Time (“FTRT”) predictive computational fire-modelling, comprising: an optional (but highly recommended) first step which involves training a computer processor to estimate, in or close to real-time and to a given level of accuracy, the Heat Release Rate (HRR) and location of a fire (“fire location”), wherein the processor creates a computational (i.e., simulated) fire model at one or more simulated locations in or on a digital twin of a built structure, wherein the simulated fire model is specified to a certain level of detail and accuracy (hereinafter, a “baseline fire model”), and wherein the estimates of the HRR and fire location of the baseline fire model are estimated based only on values of simulated sensory data (hereinafter the “simulated fire data”) pertaining to the baseline fire model, wherein the simulated fire data corresponds to data pertaining to a location within or on the digital twin (hereinafter, a “simulated first location”), corresponding to a real physical location (hereinafter, a “real first location”), at which a real fire sensor is located - it is important to distinguish the difference between the location of a simulated or real fire (being the “fire location”) and the simulated or real first location, (being the location of the sensor which detects and monitors the fire); although, by definition, the first location will be in proximity to, or at least have direct line of sight of the fire location, the two locations are almost always separated, hence the distinction between them); a mandatory second step which involves training the processor to become “Computationally Fast” at producing a predictive computational fire model (hereinafter, a “predictive fire model”, wherein by definition the predictive fire model must be specified to a level of detail and accuracy which makes it capable of being computed and run in FTRT), wherein the predictive fire model is a simulation which is based exactly on a corresponding baseline fire model in all respects save as to the level of detail and accuracy of the baseline fire model, whereby the predictive fire model will always be specified to a lower level of detail and accuracy than the corresponding baseline fire model, the method further comprising the predictive fire model created by the processor including one or more predictions of one or more physical parameters of a fire at one or more simulated future points in space and time including, but not necessarily limited to, one or more values of predicted simulated fire data pertaining to one or more simulated first locations; an optional (but highly recommended) third step comprising the trained Computationally Fast Processor (“CFP”) comparing the predicted simulated fire data of the second step to the corresponding simulated fire data of the baseline fire model of the first step, and wherein the trained CFP updates the predictive fire model using one or more algorithms of machine learning, such that the predicted simulated fire data of the predictive fire model converges, to a certain level of accuracy and within a certain amount of compute and run time, with the corresponding simulated fire data of the baseline fire model; the result being that the trained CFP is now not only computationally fast in producing one or more accurate predictive fire models, but is also trained in updating said predictive fire models with sensory data (in this step, simulated data) from a simulated fire, so that the one or more predictive fire models are dynamically adapted in real-time to be as accurate as possible (hereinafter, a “dynamic predictive fire model”). It is important to note that to the trained CFP, it does not matter whether the received sensory data of this third step is real or simulated (both types of data are simply digitised information capable of being manipulated and processed in the same way), but the use of dynamic simulated sensory data to train the CFP to update a predictive fire model (to create a dynamic predictive fire model), in realtime, so as to maximise the accuracy of the predictive model while still in simulation mode, is a key inventive concept of this method. Unless a real fire starts and is detected at one or more first locations, the method of this invention generates additional baseline and predictive fire models and simulated fire data relating thereto, and simply implements the method of the first, second and third steps to these additional simulated fire models (baseline and predictive) and simulated fire data (baseline and predictive), thereby increasing the accuracy of the dynamic predictive fire models as much as possible. The first three steps of the method of this aspect of the invention are the “training steps”, before the method (and system, in the third aspect of the invention) can “go live”, so to speak. There will therefore be a period of time, likely days or weeks, during which several thousand simulations will be run, both baseline and FTRT, and for the duration of which the ability to properly implement the fourth step will be constrained. Once the first three steps have been completed for all TVT datasets and baseline and FTRT models, the fourth step of the method is ready to begin: this is the “live” method. It is an explicit feature of the method of this aspect of the invention that, in the event of a real fire being detected in the real structure, the method could proceed directly to what is described as step 2 above (omitting the optional step 1), and from step 2 could proceed directly to step 4 (omitting the optional step 3); and while this would not be the recommended or preferred embodiment of this aspect of the invention, a 2-step process (steps 2 and 4) would work in the sense that it is possible to create an FTRT model this way, and it would be better than no model. The fourth step of the method only starts if a real fire is detected at one or more real first locations, in which case the trained CFP repeats the first to third steps of the method, except in this case it is using real sensory data detected at a real first location (i.e., real fire data) as an input to the models of any of steps 1 to 3. If the conditions should arise that the fourth step of the method is invoked (i.e., a real fire at the first location is detected), the method of this first aspect of the invention further comprises the communication to responsible agencies of the one or more outputs (defined later) of the one or more predictive fire models of the real fire (which would include, but not be limited to, the predicted path, intensity and key parameters of the real fire) based on the converged predictive fire models, such that said responsible agencies may then take appropriate action to minimise the potential for loss of life, loss or damage to property and, where applicable, the associated environmental impact, caused by the fire. The definition of responsible agencies includes firefighting and other emergency services personnel who are tasked with fighting the fire or minimising casualties, damage and spread of the fire; it also includes any automated systems or equipment (hereinafter, a “remote device or system”) which may be configured by said responsible agencies to automatically act according to received information relating to the real fire hazard. A specific example of an automated system would be the use of one or more automated fans, for the purposes of providing tactical ventilation of the fire; the processor, armed with a far more detailed picture of the development of the fire and with the benefit of continuous updates as per step 3, would be an efficient method for directing efforts to move smoke or gaseous products, produced by the fire, within the structure for tactical firefighting purposes, if it was communicatively linked to said fans; this process would also free up firefighters for other duties. We now introduce the method of each of the four steps in more detail. Step 1 (Parameter Inversion): The first step of the method comprises creating a trained CFP, wherein a computer processor is configured to produce one or more digital simulations of a fire, (hereinafter the “baseline fire-models”) wherein the digital simulations comprise all of: the simulated Heat Release rate (“HRR”) for the fire; one or more simulated locations of the fire (a “fire location”); and a first location, as previously defined, at which simulated fire data can be generated; and wherein the baseline model is created in advance of a real fire being detected at said one or more fire locations, and wherein the baseline fire-models use computational fire-modelling techniques and the processor creates baseline fire models comprising modelling parameters (mesh size) configured to produce fire models with a certain level of detail; preferably, this level of detail should be such that it means the baseline fire models cannot be created in FTRT (although the method would still work if the baseline model were capable of being run in FTRT), and wherein the baseline fire models are then split into a training dataset, a validation dataset, and a test dataset on some basis (this technique is a Train, Validate &Test protocol, or “TVT protocol” and the datasets so produced are the “TVT dataset”). The process of parameter inversion is necessary because, in the case of most fluid-dynamic phenomena, the sensory data reported back to the system to detect the phenomena is not the information required by the system to build the CFD (or equivalent alternative) models. An example, by way of explanation, is that of firemodelling within a built structure. An IOT fire sensor (equipped, for this example, with heat, carbon dioxide and smoke sensors), can only provide information on the levels and rate of change of those three variables, at the location of the sensor; when that is translated over to the digital twin in which the fire is modelled, it provides data on what the sensor sees but this is NOT want the system needs to create models of the fire. The system need two things: (1) the Heat Release Rate (HRR) of the fire and (2) the location of the fire (which is different to the location of the sensor; the sensor will of necessity, be close to the fire in order to detect it in the first place, but it will not be in the fire itself, or it would be destroyed and not transmit data). Parameter inversion is the method by which the processor “reverse engineers” (so to speak), the data that is received by the sensors (heat, carbon dioxide, smoke at the location of the sensor) and extracts from that data the underlying modelling parameters (HRR and fire location), to begin the construction of the FTRT models. Parameter inversion is achieved by means of a “top-down v bottom-up” approach, which is essentially the same method as employed by the research items (2) and (3); the difference in the case of this method is that instead of using generic real data from a real fire, in a training building created for fire testing, we use simulated data from Slower Than Real Time (STRT) fire models using the digital twin of the built structure in question; this has the enormous advantage of pre-training the processor to simulate fluid dynamic phenomena on the specific geometry of the inside and outside of the structure, since we can simulate fire, or airflow, or whatever we are interested in, as often as we like if we are simulating it digitally. This advantage is one of the distinguishing features of this method over prior art. Using the case of fire-modelling again within the structure, the method of parameter inversion in this step 1 means creating simulations of the fire using known values of HRR and fire location (because we have this from the models we have chosen to create because we would have specified these parameters to create the models), and this is the “bottom-up” portion. The output of these models will include levels of (say) heat, carbon dioxide, and smoke at all the various points in space and at each time-step of the simulation, and some of those locations will include the simulated location of the sensors within the digital twin; this brings us to the most important aspect of this step of the method: Whatever the format and type of sensory data is going to be used in a real-life event, that sensory data type must be produced by the models in this step 1, so that the processor is pre-trained on being able to interpret the sensory data and infer the underlying modelling parameters as a result. The method of this step 1 uses simulated sensory data to pre-train the processor, and this is a key part of the inventive concept of the method. The above therefore requires that, before the invention can be put in place, the nature and method for capturing sensory data in relation to the real phenomena must have been decided. As examples only: for fire in a built structure, it may be decided to capture heat, carbon dioxide and smoke (although other variables can be selected, and it could just be heat or carbon dioxide, or any combination), and once selected it must be the case that those variables are produced as outputs by the “bottom-up” simulations, so they can be fed into the neural network (or equivalent) to map the hidden relationships between the simulated sensory outputs and the modelling parameter inputs, to enable the processor to be pre-trained on this process. For a wildfire, the simulated outputs might be thermal or optical images (other sensory data is possible); for atmospheric events such as hurricanes, the sensory data might be optical (satellite) images of the hurricane and for ionospheric events, is might include total electron content and density, optical images of radiative recombination, or other information such as would be detected by an ionosonde (by way of example only). The method of this step 1 further comprises using the TVT dataset to train the processor, using techniques of Machine Learning (ML) including the use of a Neural Network (NN) or equivalent alternative method, to then “work backwards” from the simulated fire data of the TVT datasets, which corresponds to data from a simulated first location (i.e., a simulated location within a digital twin of a structure which corresponds to a real physical location at which a real fire sensor is located (if a pre-installed sensor) or directed towards (if a portable sensor) within the real structure), so as to estimate the underlying HRR and fire location which was necessary to create the baseline models in the first place; at the end of step 1, the trained computer processor can then be said to be trained to quickly estimate, in real-time or very close to real-time (say within a few seconds of receiving the simulated fire data, a time-frame which has been validated by research2), the HRR and one or more fire locations of a fire model, using only the simulated fire data from a first location as an input, which is the aim of step 1. As stated, the first step as described above incorporates a “Train, Validate and Test” process, which is a fundamental process in machine learning and would be well known to anyone skilled in the art; other equivalent processes would also be known and are deemed to be included in this disclosure where they achieve the equivalent results as the Train, Validate and Test process. Studies have shown that a split of training datasets is typically: 70% for training, 15% for validation and 15% for training, and this is an effective starting split, however other splits may improve results for certain fires and the exact split is left to the person skilled in the art to experiment with. Step 2 (FTRT Modelling): In this step of the method, the aim is to train the CFP to create, to a certain level of accuracy, FTRT fire-models which comprise the same fire location, fire type, HRR, and all other parameters as the corresponding baseline fire-models, but which also comprise modelling parameters (mesh size or node density if using a meshless model) with a lower level of detail than the baseline fire-models such that these fire-models can be created in FTRT. The FTRT models create simulated fire data at one or more locations within the spatial grid, at least one of which must be a first location (if there is one), as per the first location of the corresponding baseline fire-model. It is a rule of this aspect of the invention that, in this step 2, if a first location exists in the baseline model then simulated fire data must be produced at that first location in the FTRT model. ATVT process is then applied to the FTRT fire-models, typically with a 70% split fortraining, and 15% each for validation and testing. FTRT models use Slower Than Real Time (STRT) baseline models to train FTRT models in terms of accuracy. The method described below is for uniform mesh CFD, but the same principles apply for adaptive (non-uniform) mesh, or meshless models (wherein the STRT models would have more nodes and the FTRT models would have less nodes); this step of the method can be performed without having performed step 1, but it is recommended to combine it with step 1. For the training process, it is a preferred embodiment of this method that, subject to the rule about the first location, simulated data for many other locations in the FTRT model should be compared to the baseline dataset for the corresponding location, and at the corresponding time (we recommend 30 to 50 additional locations to the first location); in this way, a whole range of multi-variable time-series of different simulated fire data types (heat, smoke, gases etc) is built up for a range of locations in the FTRT model, which correspond to locations in the baseline model; once these two time-series are captured (the FTRT time-series and the baseline time-series), the data can be processed via a Neural Network (NN) and the underlying parameters, hidden relationships and variables between the two time-series datasets, which are expressed as mathematical relationships, can be established by the NN, with appropriate weights or biases added to each factor. For the purposes of step 3 to follow, it is recommended that that the Neural Network phase, wherein the dataset of the multiple FTRT time-series is compared to the corresponding dataset of the multiple baseline time-series to create a loss function, being one or more mathematical relationships between the differences in the time-series, and wherein the NN uses the loss function to generate adjustable weights or biases within the FTRT model, specifically excludes the simulated fire data for the simulated locations for both sets of time-series; the reason for this is that the purpose of step 3 is to specifically compare the FTRT and baseline simulated fire data for the simulated first location for a “true-up, true-down” real-time adjustment process (explained in step 3) and to avoid “over-fitting” of data, it is best to exclude this data from the FTRT training process of this step 2; the method of step 2 would work perfectly well if the simulated fire data at the simulated first location were used but it is possible not to use it for step 2 training. It is worth pointing out how to map the different time series for a cell within the CFD mesh from the STRT baseline model to the FTRT model; the FTRT model has a mesh of larger dimensions (purely to illustrate, let us say the FTRT mesh has cells which are 3 times larger in all dimensions). Therefore, for the STRT fine-grid model to cover the same space within the digital twin as the FTRT coarse-grid model, in terms of comparing simulated sensory data for pre-training purposes, it is necessary to find a way to “map” the 27 cells of the STRT model which cover the same space size as the one FTRT cell (33 = 27). There are multiple ways of doing this, but the simplest and recommended way is to simply average the values of the simulated sensory data of interest (which might be temperature, or carbon dioxide etc) across the 27 STRT fine-grid cells and compare these averages for the predicted values of the same simulated sensory data of the corresponding one FTRT cell, covering the same digital space. The differences between the corresponding time-series data points can then be processed to create a loss function, for example, using a Mean Squared Error method and possibly a Stochastic Gradient Descent technique (noting that alternatives to both these methods are available and well known); the loss function can then be minimised so as to train the CFP to produce verifiably accurate FTRT models - typical target accuracies would be for the trained FTRT model to produce FTRT models wherein the simulated fire data for any location within the model is, at a maximum, +1-15% from the simulated fire data of the baseline model at the corresponding location and time (i.e., time-step). Once the training aims have been achieved, the validate and test process can be applied (using the same number of locations as the training model) and the CFP should then, at this point, be said to be a “trained Computationally Fast Processor”, (hereinafter a “trained CFP”) when the outputs (defined later) of the FTRT predictive fire models achieve a certain level of accuracy compared to the test fire model datasets. This process is repeated as often as is required for the CFP to consistently acquire the minimum target level of accuracy for the validation and test datasets, as compared to the FTRT fire models; if more FTRT and baseline models are required to achieve target accuracy, or if more locations are required for a comparison of simulated data (say 100, or 200 instead of 50), in order to expand the dataset of comparative FTRT and baseline time-series and establish even more accurate adjustments to weights or biases, then so be it. Key outputs from the FTRT models at the end of this step 2 include either, or both, of the current-state (at a given point in time) or one or more predictions of the future state (the future being defined as any point in time after the current-state) of any or all of: • the HRR of the fire; • the intensity of the fire; • the presence and composition of smoke or gases; • smoke or gas development or movement related to the fire, including any properties of the smoke or gases including any or all of: direction, composition, density, or temperature of said smoke or gases; • the path of the fire; • the physical spread and I or rate of physical spread of the fire; • the physical spread and I or rate of physical spread of smoke or gases; • calculated safe routes for zones of occupation (regardless of whether there is occupancy detected at the time of the fire), wherein a safe route is defined as a route from a zone of occupation to a place not under threat from the fire, wherein the route avoids proximity to the fire hazard’s current or predicted future path or locations, and wherein: o a fire hazard relates to any of the heat, smoke or gases produced by the fire; and o a zone of occupation means a place where people are likely to be found, or actually are found, including (but not limited to) rooms or residences in the case of a fire in a structure (building, vessel etc). Any of the foregoing outputs could be represented in the form of a 2-dimensional or 3-dimensional digital representation of the first location and the environment surrounding the first location, or of which the first location forms a part (such as a representation of the entire structure in which a fire has started). The trained CFP should produce such outputs using simulated data, to be trained in real-time production of FTRT outputs in the best format. A simulation of the real value of the outputs described in the foregoing will be created in the event of a real fire; the primary aim of the invention is to produce these outputs in FTRT, should a real fire occur, and then update them with a continuous stream of real fire data from the real first location (as per step 3). Step 3 (Convergence): The third step of the method is dependent on the second step and is optional, although recommended in preferred embodiments of the method of this aspect of the invention; the aim of this step is to update the FTRT models of step 2 by means of configuring the trained CFP of the second step to receive, from a baseline model (any baseline model, such as the TVT dataset of step 1, or a different baseline model of step 2, or a further independent set of baseline models for the purpose of this step 3), simulated fire data corresponding to one or more first locations at one or more points in time (being sim-time, i.e., fire data at multiple time-steps in the simulation), and wherein the receiving of this data is intended to simulate how the system would react to a real fire, whereby real fire data from one or more real first locations would be detected by real sensors, and sent to the trained CFP for processing, on a continuous basis. In this third step whereby a real fire has not been detected, and the system is in constant training and simulation mode, the values of the simulated FTRT fire data (at certain pre-determined time-steps) are compared to the corresponding simulated fire data of a more accurate baseline model for the same simulated first location; the CFP then measures the difference between the two values, on an ongoing basis, and then further adjusts the weights or biases of the FTRT model of step 2, so as to minimise the differences, over time. The benefit of using this third step when there is no fire is to simulate “live drills” for the processor, such that a simulated event (fire, or non-fire) can be run with simulated sensory data, the first step of parameter inversion (if used) could be run using this data to estimate the underlying modelling parameters, the second step could be run to model the phenomenon in FTRT (using the underlying parameters of step 1, if available), and then the feedback loop of this stage could be trained to accurately incorporate the simulated sensory data, compare it to the predicted data of the FTRT models and then adjust the weights and biases of the models to in crease accuracy of the FTRT models, overtime. A further benefit of this approach is the ability to simulate other aspects of the system, such as simulating IT outages in the network, sensor outages, failures in compute or memory resources, in order to test the resilience of the overall system. There are multiple methods by which the system could adjust the FTRT models, and further on in this document we will disclose two such methods, being the “stop-start method” and the “continuous method”; which of these two methods chosen by the skilled practitioner would, in some measure, be determined by the power and specification of the computer processor and associated RAM (Random Access Memory), and if the processor specification allows, it is recommended that both methods be used (either in parallel or in sequence) to determine which provides the quickest and most accurate route to convergence. The cumulative effect of these processes of step 3 is that the simulated fire data of the FTRT models should, over time (sim-time where no fire has been detected, or real-time if a real fire has been detected), converge more closely to the simulated fire data of the baseline models (or the real fire data if a real fire were detected), further enhancing the accuracy of the FTRT models; we call this process of improving accuracy “convergence”, and we speak of the FTRT model as “converged” when it reaches a target accuracy level and stays within that level for the duration of the remainder of the sim-time. In this way, the FTRT or predictive fire-models of step 2 will become dynamic FTRT or predictive fire models of step 3. The property of convergence requires, by definition, that the predictions are aligned with the simulated fire data in terms of what is being actually represented by the simulated fire data, the time-step in the simulated fire at which those values are simulated, and the representation format of the simulated fire data, in order that the measured difference between the predicted and simulated actual values has meaning and can be acted upon by the trained CFP. For the purposes of this invention, there are two broad categories of sensory data (whether simulated or real), which relate to two different types of information on the fire, or any other phenomena being modelled, and it is a fundamental aspect of this method to pre-train the system using simulated sensory data, of any relevant type, which provides significant advantages when the phenomena to be modelled is high-risk (fire) or outside the control of human beings (atmospheric events), such that simulated data is the only way of practically acquiring training data for pre-training a system. The foregoing is true because for computational training purposes, there is no distinction between real and simulated sensory data (both, in the end, being binary data i.e., “ones and zeroes”), and in this way the ability to accurately pre-train a system against a specific type of phenomena, in a specific digital twin of a built structure or natural environment, is a distinct advantage over the prior art. The two different classifications of sensory data are: 1. Macroscopic: this refers to data which relates to physical information on a broad physical scale, i.e., data which simultaneously refers to a relatively large physical location, defined as a large group of contiguous points. Examples of broad-scale fires which would give rise to macroscopic data include: a fire on the external cladding of a building, or a fire in a storage depot or other similar open groups of structures, or a wildfire, or satellite images of a hurricane, or radar I radio images of the properties of an ionospheric or geomagnetic disturbance. Macroscopic data will, in general, tend to be received by the CFP for fire-modelling in the representation format of an ordered sequence of images, either optical images or thermal, with thermal images being the preferred data format. For atmospheric and ionospheric events, the macroscopic data could be optical and thermal images (optical usually preferred), or radio I radar generated images and data (e.g., as per an ionogram). In the case of optical images of a fire, the trained CFP would need to infer the HRR and location by converting the optical images into thermal data which can then be modelled and interpreted; there are a variety of techniques for doing this, well known to persons skilled in the art, and the trained CFP would have to be configured to carry out these processes. In the case of thermal images of a fire, the thermal data is already presented to the trained CFP which can immediately model the fire from it. 1. Microscopic: this refers to data which relates to physical information on a narrow physical scale, i.e., data which simultaneously refers to a relatively small physical location, defined as a single point or a small group of contiguous points. Examples of narrow-scale fires which would typically give rise to microscopic data include a fire inside a building, vessel, or other structure. Microscopic data will, in general, tend to be received by the CFP in the representation format of an ordered sequence of data points such as temperature, smoke levels, toxic and hazardous gas types and levels at one or more points in time (bearing in mind that some gases, e.g., carbon dioxide, are only hazardous above certain levels, while other gases, e.g., hydrogen cyanide, are hazardous at any level above trace levels). Microscopic data typically refers to any sensory data detected by smoke, heat or gas sensors which may either be pre-deployed in a location prior to the start of a fire, or deployed in response to a detected fire. The above difference between macroscopic and microscopic data is not intended to be prescriptive or subject to “hard-and-fast” definitions; the definitions are context-specific and there can be crossovers; for example, microscopic-type fire data such as from a fire inside a building can still be captured by macroscopic-type sensors such as handheld thermal imaging cameras. In general, in the context of this invention, the data relating to a fire (wherever it is located) is defined as macroscopic if it is captured in the form of images (optical or thermal), and microscopic if captured by smoke, heat or gas sensors. The importance of the type of data representation is that the CFP should be pre-trained in the interpretation and modelling of fires, for a given pre-determined first location, using all the different types of representation format which are likely to be deployed prior to, or in response to, a fire at the fire location. It is straightforward to represent microscopic data as it will be received as a time-series of values at a particular location; with macroscopic data, it is necessary for the trained CFP to be configured to receive and interpret image data (optical or thermal), and use that as the basis for predictive fire-modelling. It is also necessary for the trained CFP to be able to represent the output of the predictive fire models in the same format as the data was received (i.e., if received in thermal image format, the predictive output should, as far as possible, be represented in thermal image format, allowing for the fact that some outputs may be represented in additional ways, such as specific temperature estimations accompanying the thermal images, or advice which would be in language). The choice of output representation would be made by the agency using it, and the capability to adjust the format as required is a preferred method of the invention. The method of the invention stays at the first to third steps (wherein the first, second and, if chosen, third steps can either run independently on different datasets, or wherein the second is dependent on the first (the third is always dependent on the second), or both independent and dependent scenarios are employed), and comprises the ongoing and continuous creation of further TVT and FTRT fire models, with the effect of continually enhancing the accuracy of the output of either or all steps as far as possible; as an example, if 1,000 baseline models are created for step 1, and therefore another 1,000 FTRT models are created for step 2, and then these 1,000 FTRT models are updated using step 3, the method of the invention would be to add one more model to the datasets, then one more such that the number of datasets would be 1,001 for each step, then 1,002 etc and by this means the cumulative amount of data available to the Neural Network will always increase, the relationships between the hidden variables will expand, and the weights or biases at each step will become increasingly more accurate, tending to a maximum overtime. The method only invokes the fourth step in the event of a real fire (or real other non-fire fluid-dynamic event) being detected at the first location. Step 4: As previously stated, this step is only invoked if a real fire is detected at a real first location (i.e., by a sensor located at, or directed towards, a real first location); in such a case, the CFP will receive actual data from a real fire (hereinafter, “real fire data”) and will follow the process described in the first three steps, with the exception that the CFP will use real fire data from the real first location, instead of simulated fire data from the simulated first location. In practical terms, the method of this step is as follows: 1. Once a real fire is detected, the processor will start to immediately (or within a few seconds subject to network latency) receive real fire data from a connected sensor at a real first location; 2. The trained CFP will start to immediately estimate the HRR and real fire location (which step 1 has trained it to do); 3. The trained CFP will then, within a matter of a few seconds (less or more, depending on the power of the computer processor) start to create FTRT fire-models using the estimated real fire location and HRR as the underlying modelling parameters (which step 2 has trained it to do); 4. The trained CFP will then continue to receive a continuous stream of real fire data from the sensor as part of the ongoing monitoring of the fire, and will update the FTRT models with this data, in order to create convergence between the FTRT models and reality (as step 3 has trained it to do). The other difference between the fourth step and the first to third steps is that the CFP will, in the case of a real fire, send the output of the predictive fire models (as defined in the introduction to step 2, above) to responsible agencies; this will be achieved by sending information regarding the outputs of the predictive fire models in visual or audible form to one or more remote devices or systems. An optional extra aspect of these outputs, for this step 4 of the method, is for the CFP to act as an advisory system for said agencies on how best to deal with the fire (the outputs from the fourth step being the same outputs as described in the first to third steps, but using real rather than simulated data). This would be done by, for example, highlighting safe routes, drawing attention of the responsible agencies to predicted fire spread and intensity and any implications relating thereto; such advice will vary according to the specific scenario for each fire and structure. Examples of responsible agencies include: fire and rescue services, other emergency services, military services, and any sub-contractors or other local or civil partners that any of the foregoing need to engage to fight the fire. Additionally, it is within the scope of the method of this invention that one or more remote devices or systems which are, or may be, configured by any responsible agency to take an action in response to either of: 1. an instruction from the responsible agency, wherein the instruction is based on one or more outputs from the trained CFP of this method; or 2. an automatic action in response to one or more outputs from the trained CFP, wherein the output is communicated to the remote device or system; are considered to be included in the definition of a “responsible agency” and such items would include (but not be limited to): one or more automated fans for the purposes of tactical ventilation, being the forced movement, or restriction of movement, of smoke or gases produced by the fire by means of increasing, or decreasing, air pressure or air flow within or on a defined space within, or on the surface of, a built structure; one or more automated hoses for directional suppression of a fire; third-party fire alarm protection systems; automatic firedoors; automatic sprinkler systems; automatic fire suppression systems; third-party structure management systems; third-party structure evacuation systems; third-party digital voice assistants, drones, other unmanned or manned vehicles which travel by land, sea, air or space - the foregoing list, which is not exhaustive, are considered to be remote devices or systems. Where required, the location of the automated systems such as fans or hoses described above would need to be communicated to the processor, so that it could calculate optimal angles for the ventilation or suppression techniques; additionally, the capacity of said fans or hoses would need to be communicated, so that the processor could monitor and direct the ventilation or suppression efficiently. CFD modelling: As stated already, the applications of CFD for the method of this invention; firstly, creating a TVT dataset of CFD applications for the CFP to become trained on how to infer HRR and fire location of a fire from simulated fire data as per the first step, secondly the use of the trained CFP to create FTRT fire models in the second step, thirdly the use of the trained CFP to update the FTRT fire models with simulated fire data in the third step such that they converge with the baseline models to a certain degree of accuracy, and fourthly to repeat all three steps using real fire data from one or more real first locations, in the event of a real fire being detected. At this point, we should consider the software which might be used; the CFD algorithms, well known to persons skilled in the current art, are differential equations based on either, or both, of the Navier-Stokes equations of the 19th century, and I or the Euler equations of the 18th century; these equations are taught in practically every university engineering or physics degree in the world, so are deemed to be universal in terms of dissemination; it is perfectly possible for a skilled practitioner to design their own code to implement these equations (NASA, for example, is well known for doing so), but it is also the case that there are very many commercially available software packages with these algorithms already pre-built, and such packages are often optimised for cloud computing and parallel processing (which is desirable to enhance calculation speed). For this reason, preferred embodiments of this method are to use commercial CFD software packages, while noting that self-coded software is viable, but timeconsuming to create. The key factors which influence accuracy and modelling-speed (and which create the trade-off already noted, between the two) are physical grid-size (spatial) and time-step (temporal). These two spatial-temporal concepts determine run-time and accuracy; the smaller they each are, the more accurate the models but the longer they take to run (more computations). The first step simply requires the creation of enough training simulations to train the CFP; research2 (Zhang et al) indicates that 500 to 600 models, with a grid-size of 10cm (i.e., a regular cube of 10cm on each side) would provide a TVT dataset which would achieve close to 90% accuracy in terms of HRR and location estimation, with a delay of 1 to 2 seconds against real-time; the method disclosed in this research would work for step 1 of this method, although it is noted that there are other methods which would be known to persons skilled in the art. It is important at this point to note the significance of the 10cm grid-size for training the CFP and the underlying principle; the smaller the grid-size of a CFD simulation, the more accurate the simulation but the longer it takes to be created (hence the fundamental and already noted trade-off between speed and accuracy of CFD modelling). In the case of a building fire, an average compartment would have a height of about 2.5m (and typically a length of 7 to 8 metres and a width of 5 to 6 metres), which means that, in preferred embodiments, the minimum ratio of the space to the grid-size, for TVT datasets, should be in the 25:1 region (there are 25 x 10cm grids in a 2.5m height). Preferably the TVT dataset (of baseline models) should be of a grid-size small enough that it would not be practical to run in real-time (hereinafter, a “fine-grid”, and the research by Jahn indicates that this is anything smaller than a 25cm grid, allowing for improvements in computational modelling since 2021 when the research was published); the significance of the 10cm grid is that the 25:1 ratio in a typical environment (i.e. the height of a typical building compartment) is a good indicator of a ratio for a fine-grid simulation, in terms of the ratio of the grid to the minimum smallest dimension of the space for which the fire is being modelled (height, width, length; usually height is smallest of the three dimensions). In terms of the time-step, this is to a certain extent based on the experience of the skilled practitioner and is largely influenced by the speed and accuracy desired of the model; the skilled practitioner would know how to calculate this, but a good initial range would be somewhere between 0.0001 seconds and 0.001 seconds, per calculation step; but it could take any value. In terms of the step 2 of the method, it is necessary to use a 4-dimension mesh which is considerably larger than a fine-grid mesh, such that the model can be run in FTRT and trained by reference to the simulated data of the baseline models; the FTRT modelling is called “coarse-grid” modelling. Research1 (Jahn et al) indicates that FTRT modelling is realistic anywhere above 30cm grid-size and this gives us another ratio for the coarse-grid modelling; in general, and subject to certain limitations, in preferred embodiments of this method, the ratio of 4-dimensional mesh size for coarse-grid modelling in the second step should be at least 3 times larger than that of the 4-dimensional mesh of the first step (for the baseline models); in the case of a building compartment, that means there would be a minimum of 8 grids in the 2.5m height (250cm divided by 30cm), which is important because it is generally known that CFD models start to lose predictive accuracy when the number of grids is less than 8 in any direction. In terms of time-step, one would start with the same ratio (3 times) and evaluate performance based on this, adjusting as necessary to achieve target run-times and accuracy. So, for the second step, the coarse-grid should be at least 30cm (if the fine-grid were 10cm) in the case of a room or compartment fire simulation. These grid-sizes are variable based on the different types of fire being simulated, which is why ratios serve better than absolute measurements; that said, there are certain limitations to the ratio method. For example, in a building fire it is perfectly possible to use a smaller fine-grid size, such as 5cm, but then it would be impractical to use a coarse-grid of 15cm (3 x 5cm) because it would take too long and not be FTRT. Equally, it is important to note the “rule of 8” which says that the preferred minimum number of grids in the smallest dimension of a fire-modelling volume of space is 8 grids (this is not prescriptive, it is simply optimal and therefore preferred); there should be at least 8 grid cells in every axis of direction within a volume of space which is to be modelled for fire. This enables us to make some rules as to the preferred embodiment of the method of this invention, when it comes to the crucial step of grid-size selection for the spatial dimensions of the first and second step CFD fire-models (noting that other embodiments are possible): • For a fire in a structure, the maximum grid-size for the fine-grid modelling of the first step is 10cm (smaller grids are perfectly valid, e.g. 1 cm or 5cm); • For a fire in a structure, the maximum grid-size for the coarse-grid modelling is the smaller of: o a 30cm grid, ora grid no greater than 1 / 8thofthe smallest dimension of the compartment or area of the structure for which the fire model is being created (usually, the height of the compartment); • For an open fire, the maximum grid-size for the fine-grid modelling of the first step is 1 / 25th of the estimated average height of the structures (or vegetation) in the area to be modelled; • For an open fire, the maximum grid-size for the coarse-grid modelling is 1 / 8th of the estimated average height of the structures in the area to be modelled (which also approximates to 3 x the fine-grid height), wherein such structures may be built or grown (i.e. vegetation). It is often the case that the model can be made FTRT simply by varying the spatial dimensions and keeping the same temporal dimensions (i.e., time-step as a fraction of a second), and the preferred embodiment is to try and make the model FTRT by varying only the spatial dimension (along the lines specified above) and only varying the temporal dimension if still required, and then only by as much as needed to meet the FTRT target. Time-step changes are best left till last. The above are examples only; other grid-sizes and time-steps are perfectly possible and it really depends on the desired accuracy and speed targets of the skilled practitioner; such considerations inevitably will require some experimentation. In step 3 of the method, the FTRT models are kept accurate through the convergence mechanism, by means of continuous updates of simulated fire data from the baseline models. In the above method, the computer processor must have access to certain location-specific information; a mandatory requirement is access to a stored memory comprising the layout of the structure or a plan of the open-space (typically, a relief map) and of any structures of vegetation therein; it is also mandatory to have in the stored memory information to identify any first location, if pre-installed sensors are used; additionally, it is desirable (although not fundamental for the execution of the method) for the processor to also have access to a stored memory comprising supplementary location-specific information, such as the construction methods and materials of the structure, together with reference data on the ignition and combustion time and temperature of the structure materials, the chemical products resulting from the combustion of the structure materials, as well as information on the location and type of fire-protection (detection and monitoring equipment), and fire-mitigation (sprinklers or gas suppression) systems which may be in place. It is therefore an important aspect of the method that a detailed structural survey of the structure is undertaken prior to the deployment of the Appliances, or that data from such a survey (if already undertaken) is provided to the skilled practitioner, to capture (as a minimum), the layout of the structure or open space and, ideally, the supplementary location-related information described above. The aim of the survey is to be able to render the output of the current-state or predictive fire-models in a 2D or 3D digital representation of the layout of the structure, to be sent to responsible agencies as required in the event of a fire; this is an important output. Al and ML tools: As already stated, the Train, Validate and Train process is a standard machine learning technique, well known to a skilled practitioner, and is the industry-standard process fortraining a neural network. Training one or more neural networks is a crucial part of the method of this invention; a neural network is a method for a system to learn hidden features and associations between variables from input data before computing output values, using well known algorithms for discerning the optimal internal parameters, including weights or biases, based on the TVT dataset. There are alternative ML techniques to neural networks which may be used by the skilled practitioner to implement the method of this invention; such techniques include Random Forests, Support Vector machines, K-nearest-neighbours, and Symbolic Regression. All such techniques are considered equivalent to neural networking in terms of the scope of the method of this invention, but since neural networking is the main technique used for ML applications worldwide, the remainder of this description is focused on this technique, by way of example only, because the research already referred to uses this technique to implement certain aspects of this method. A detailed description of how to implement a Neural Network (NN) is not required herein, since it is an industry-standard tool (indeed, it is the industry-standard tool), and it is left to the skilled practitioner to know how to implement a neural network, but it is helpful to explore some of the different types of neural network and key algorithms which might be used to optimise internal parameters. There are different types of neural network, such as a general Artificial Neural Network (ANN), a Recurring Neural Network (RNN), and a Convolutional Neural Network (CNN); all could be used to implement this method, but the research used CNNs for the ML aspects of the first and second steps. The common theme in how an NN works is to take input variables, learn the hidden internal parameters and associations, mathematical relationships etc, ascribe hidden weights or biases which can be used to adjust outputs based on the provided inputs, establish error rates relating to key outputs (for example, by comparing the outputs to an externally provided target, which would include the TVT dataset), and adjust the “hidden” weights or biases to minimise the difference (error) between the calculated output of a layer, and a given target. The target can be a final target, such as the TVT dataset, or it can be a calculated “interim” target provided by a “hidden” layer of the NN. NNs are composed of “layers” of digital calculating capabilities (often called a perceptron), which take an input, make a calculation, and provide an output; the output may be a final value (in a very basic NN), or might be another perceptron layer, which leads to another and so on. The more layers an NN has, the “deeper” it is said to become. A Deep CNN would be a good example of an appropriate system to implement the method of this invention. The first input layer and the last output layer are considered “visible”, because they contain values which are externally visible, and the intermediate layers are called “hidden”, because they are internal to the NN structure. A key algorithm used in an NN is the method used to detect the differences between the output of a layer (hidden or visible) and the target for that output. The difference is known as the “error”, and in preferred embodiments of the method the technique used would be to find the Mean Square Error (also known as R2), being the average of the sum of the square of the observed errors; the values of R2 for different simulated points in time are used by the system to create a loss function, and the NN system calculates the value of R2 across all the layers of which it is composed, adjusting weights or biases in order to minimise the value of the loss function, which is then used to adjust how the model calculates; R2 is not the only error value for calculation of the loss function; other error values are the square root of R2 (being, of course, “R” itself), also known as Root Mean Square Error, and there are other methods well known to skilled practitioners. In general, the error detection and correction method described above is an exercise in mathematical regression and an industry-standard technique is called Gradient Descent (GD), of which there are several sub-types such as Batch Gradient Descent (BGD) and Stochastic Gradient Descent (SGD). There are many other sub-types of GD, including Fast GD methods, Accelerated GD methods, Optimised GD methods, Fast Proximal GD methods and others, all of which would be known to the skilled practitioner, and which may be suited to the execution of this method. There are alternatives ways to train an NN to Gradient Descent, including (but not limited to) the use of Simulated Annealing, Evolutionary Algorithms, Particle Swarm Optimisation, Alternative Direct Method of Multipliers, and others. Each method has its pros and cons, but research shows that the implementation of SGD to the NN training provides acceptable results. Research indicates that the use of a Deep CNN (DONN) for the first step, and the use of either another DONN or an RNN in the second step, is an example of an effective possible set of techniques to implement the method of this invention. Network: A key part of steps 1 and 3, as already noted, is the receipt by the computer processor of sensory data from so-called “smart” sensors at or near the location of a real fire; the term “smart” sensor herein is intended to refer to sensors which are connected, either wired or wirelessly, to the internet by means of the “Internet Of Things” (IOT), and will be referred to as “IOT sensors” hereinafter. The method of connection of the IOT sensors to the internet may be any of the following: one or more sensors may be connected through a local hub, through wired or wireless means, wherein the hub is then connected to the internet through the public network by wired or wireless means; or one or more sensors may be connected to the internet directly by means of a wireless communications capability (typically but not always a mobile SIM installed in a sensor, which may be a narrowband IOT SIM or equivalent), typically connected to the internet via a 3G, 4G or 5G public network, or equivalent; there may also be a failover network whereby the wireless capability of the one or more sensors is connected to a Satellite network, to ensure there is never a loss of communication. By this method, the IOT sensors may also be connected to a remote device to perform one or more actions in response to a fire, including but not limited to sending an alert to one or more users to take an action, wherein the one or more users may be an building resident, occupant or a member of a responsible agency. By any of the above methods, the IOT sensors in the building to be protected by the method of this invention could then connect to the computer processor, so that the processor may receive the IOT sensory data in the event of the fire, and so execute the disclosed method of Steps 1 and I or 3. Figure 14 illustrates an exemplary FTRT computational modelling system 1000 (single occupancy network) according to embodiments of the present invention; the term “occupancy” here meaning not the number of people, but the number of different logical IT networks within the structure; for example, hotels, university campuses, hospitals, single organisation office blocks are all examples of single occupancy because in each case there will be a single IT network for the structure, whereas residential blocks and multi-organisational office blocks are examples typically of multi-occupancy, because each different resident is likely to have their own independent network and connection to the internet (i.e., multi-occupancy tends to be multiple logical entities, each of one or more families or tenants, whereas single occupancy means one logical entity, per structure). It is highly likely that, in the case of a crewed vessel, the vessel will be single occupancy as defined above. For the purposes of IT security, it is recommended that the IOT sensors are connected as part of a single-occupancy Local Area Network (LAN), even for residential and commercial structures which have multiple separate occupants (families, tenants etc), and this is the preferred embodiment of the method ; such a network may be a hierarchical network (whereby the IOT sensors communicate via a local hub before connecting to other sensors, remote devices or the internet); or it may be a full-mesh network (whereby a “full-mesh” is a peer-to-peer, non-hierarchical network in which any device can communicate directly with any other device which is part of the network, and each device may communicated directly with the internet; or, the LAN may be a hybrid network, which is a combination of partial-mesh and hierarchical network; the preferred embodiment of this method is a full-mesh network, for reasons of flexibility and improved network resilience, but the other approaches disclosed herein would also work. In preferred embodiments, the devices will connect to the internet and then to the computer processor by means of a secure Wide Area Network (WAN) or equivalent; it is recommended that the WAN be encrypted and be configured as a Virtual Private Network (VPN) or equivalent, connected to the computer processor. Once the computer processor has performed the fire-modelling of Steps 1 or 3, it may then communicate any of the outputs of said fire-models (baseline or FTRT) to any logically connected device via the internet or other available network that is authorised to receive said communications; such outputs may contain data relating to the fire, the fire-models, occupants, safe routes, firefighting tactics or interventions, and may be in the form of a 2D or 3D digital representation of the structure; such outputs may be configured to instruct a remote device to take an action in response to the fire, or to alert a user equipped with an audio or visual interface to take such an action. Real-Time Sensory Information: In terms of the sensory data detected by the IOT sensors disclosed in the foregoing section, there are many physical parameters which may be captured and may be of interest to the computer processor, for the purposes of accurately modelling the fire and the associated thermochemical reactions caused by it. Chief among these are the following examples of localised data, to be detected by IOT sensors, and wherein, in the context of all aspects of this invention, the embodiment of the term “fire data” (whether real or simulated) includes either, or both, of an absolute level at one or more points in time, or a rate of change over time, of any of: • temperature; • thermal imaging; • flame; • smoke levels; • smoke density; • airflow; • oxygen; • carbon dioxide; • carbon monoxide; • humidity; • hydrogen cyanide; • hydrogen chloride; • sulphur dioxide; • nitrogen dioxide; • a fuel gas (a gas connected to a mains supply for the purpose of providing energy, such as “natural” gas); • hydrogen; • methane; • ethane; • propane; • butane; • ethylene; • propylene; • hydrogen fluoride; • fluoroethane; • other Volatile Organic Compounds (VOCs). In some cases, special risks may be identified through the detection of simultaneous sensory data, for example the simultaneous detection of at least two of any of hydrogen, ethane, methane, propane, ethylene, propylene, butane, hydrogen fluoride or VOCs is a strong indicator of thermal runaway cause by an over-heating Lithium-Ion Battery, which releases considerable heat and quantities of toxic and explosive gases, and which would signify an especially threatening fire hazard. All or any of the above may be detected by appropriately configured IOT sensors and such sensors may be of the type pre-installed in the structure, or may be carried into the structure in response to a fire by members of a responsible agency (such as the fire service), or may be installed on a remote device which is controlled or configured by members of a responsible agency and is intended to search for fire hazards within a structure (e.g., a suitably configured drone). It is an important aspect of the invention that the location of the sensor also be relayed to the computer sensor, in addition to the sensory data it is configured to detect, to ensure the fire-models are as accurate as possible. The real-time sensory data disclosed above may, as stated, be in the form of absolute levels at certain times, or rates of change of levels over certain intervals of time, and in preferred embodiments any of the sensory data disclosed above will be in the form of a time-series, to enhance fire-modelling accuracy. Computational Platform: The computational platform in which the fire-modelling computer processor is installed may be either a cloud-based platform, or a dedicated or partitioned physical computer; for scenarios involving fixed structures (buildings, oil-rigs, oil storage depots etc), a cloud-based platform is preferred and for crewed vessels, it is likely that an on-board physical computer will be preferred. The above notwithstanding, any combination of cloud-based and I or physical computer would work for both either fixed structures or vessels and all such variants are considered to be disclosed by this method. General Method: As stated, there are four steps to the method of this aspect of the invention and we now disclose a more detailed example of how the method may be executed; there are equivalent methods which deliver the same or similar results, by any of the methods disclosed previously or which would be well known to a notional skilled practitioner. Step 1: (a) A digital-twin of the building (hereinafter, the “digital twin”) is provided and uploaded to a computer memory to which the computer processor has access. The digital-twin will have, as a minimum and as mandatory, data disclosing the layout of the building and the location of all IOT sensors (if any) to be connected to the computer processor by means of an appropriate network, and additionally may contain any of the following optional, supplementary data: i. the materials of which the fire-rated compartments are made ii. the dimensions of the external boundaries (walls, ceilings, floors) of the compartment; iii. information relating to the fire-rating of the compartment; iv. construction methods of the compartments and communal areas (corridors, walkways, stairwells); v. construction methods or materials of internal walls of the compartments; vi. dimensions of internal walls of the compartments; vii. location of, and materials used for, electrical sockets, circuits and conduits and I or power ratings for all of these; viii. location of lifts; ix. construction material or methods for any store-rooms, rooms which contain any equipment or machinery used in the building; x. conduits and mains supplies layouts and circuitry of any of electricity, water, or fuel gas; xi. HVAC (Heating, Ventilation and Air Conditioning) data, such as conduits for air and heat circulation, type of HVAC equipment used; xii. Fire-protection systems installed, such as the location of fire extinguishers, fire-doors, fire alarm sensors, fire suppression systems (such as sprinklers or gas suppression systems); xiii. general data on ignition temperature of any of the materials disclosed in the foregoing, and also of any of the gases disclosed in the section on real-time sensory data. (b) Once the building layout has been uploaded to an accessible memory, further optional information which may be uploaded includes any of: one or more privacy policies, one or more evacuation policies, or one or more firefighting policies, relating to the building or the fire service protecting it. If such additional information is uploaded, the computer processor may, optionally, be directed to reference any such policies, as appropriate, during the course of a real fire emergency. This policy-based approach is preferred, but not mandatory, for the execution of this method. (c) Once the digital twin (and, if available, one or more policies from section (b)) are uploaded to an accessible memory, the computer processor begins the training phase (the TVT process referred to earlier). A TVT dataset of baseline (fine-grid) fire-models is simulated using CFD software (either self-coded or, more likely, commercially available). The sim-time can be anything the skilled practitioner sees fit to set it at, but our research indicates a sim-time duration of 30 minutes is enough to model the growth and steady-state development of a fire, and is also a sufficient duration to predict in FTRT and give the fire services time to act. The grid-size can be anything the skilled practitioner sees fit to set it at, although our research indicates that a 5cm grid strikes the right balance between being fine enough to be acceptably accurate and capable of being run within a reasonable time (our research indicates between 100 and 150 hours, depending on the specification of the computer processor; the advent of cloud-based High Performance Computing (HPC) and the ability for such machines to parallel process using techniques such as multithreading mean such simulations can be potentially modelled much faster than disclosed above, hence why cloud-based HPC is the preferred embodiment of the computer processing aspects of this invention. The final parameter to be chosen is time-step (interval for which the calculations are resolved and iterated), which is the temporal equivalent of its spatial counterpart, grid-size. This can be set at anything the skilled practitioner sees fit, but our research indicates a time-step of between 0.0001 seconds and 0.001 seconds is a good place to start. It is also necessary to make assumptions about the type, location and mass of combustibles that would typically be present in a compartment (which would vary depending on whether the compartment was used for residential purposes, or commercial purposes); such combustibles would include size of furniture and furnishings (curtains, walls, floor coverings etc), materials of manufacture, density and mass etc. These parameters could be set to vary for different simulations. Once the above parameters are set, the remaining step is to select the type of fire to be simulated: this can range from electrical fires, cellulosic fires, explosive gas fires, flammable gas fires, hydrocarbon and VOC fires, polymer-based fires and any other type of material capable of combustion. Such parameters can be developed in self-coded software by a skilled practitioner, but all these types of fires are capable of being pre-loaded into commercially available software for ease of application. With the above choices made and parameters set, the skilled practitioner may start to simulate fires: we recommend between 500 and 1,000 simulations should be created as the initial TVT dataset; we also recommend that fires should be simulated in different locations within buildings, and be of different types (as disclosed previously), with different combustibles, in order to prepare a thorough training set for the processor. The different choice of fire type and location can be selected individually by the skilled practitioner, or selected using some randomised method. Once selected, the processor then runs all the simulations and creates a database of all the outputs, including the simulated fire data at each simulated first location, per the digital twin (it is important that the type of sensory data which the simulated IOT sensor is configured to be able to detect is known to the computer processor, so it can map more than one type of simulated fire dataset for the simulated first location, at one or more simulated times; the simulated fire characteristics include HRR, location, and the simulated outputs of the fire which correspond to the fire-data disclosed in the section on real-time sensory information (e.g., heat, smoke, certain gas levels etc). The use of cloud-based HPC becomes valuable at this stage, which is the most time-consuming phase, because multiple fires can be simulated in parallel (basically, without limitation) and so what would be 100,000 hours of simulations (if run end-to-end, sequentially) can be run in massively parallel fashion, and so the entire TVT dataset can be produced in a few weeks, or even within days if enough computing resource is recruited to run the models in concurrent batches. (d) The next stage is to train the processor to become a CFP (Computationally Fast Processor) in terms of inferring fire location and HRR from the simulated fire data (e.g., heat, smoke, gas levels) at the simulated one or more first locations: this is done by using a Neural Network (NN) and although many types of NN can be used, research including that by Zhang et al2 indicates a CNN (Convolutional Neural Network) is an optimal model; our recommendation is to use a Deep CNN (DCNN) with at least 5 hidden layers, to achieve optimal results. (e) We recommend a TVT dataset split of 70% of the simulations for Training, 15% for Validation and 15% for Testing. The method of how to achieve the training will be well known to any skilled practitioner, and an example of how this may be achieved is shown in the research2 by Zhang et al. The error correction for the ML algorithms is recommended to be Stochastic Gradient Descent (SGD), but equivalent algorithms and techniques can be used based on the preferences of the practitioner. The NN uses the SGD technique to adjust the weights or biases of the hidden variables within its internal hidden layers, until satisfactory accuracy is achieved. As already disclosed previously, any equivalent to an NN is acceptable for this method and may be used, depending on the preference of the skilled practitioner. The important deliverable of this step is that at the end of it, the processor has been trained to be Computationally Fast at estimating the fire location and HRR based solely on the simulated fire data at various simulated first locations within or on the digital twin, wherein the fire-data is of the type and format likely to be received from real sensors in a real fire. (f) If the level of accuracy of section (e) above is not achieved after 1,000 simulations, then further simulations should be run and added to the TVT dataset until desired accuracy is achieved (it is a feature of ML that, provided enough data is provided for analysis, accuracy can be arbitrarily increased although this is subject to the law of diminishing returns). Step 2: (a) The aim of step 2 is to train the system to create fire-models in FTRT by using an appropriately larger grid-size and time-step (we recommend 3 times larger in spatial and temporal terms, but other scaling ratios are acceptable), and which uses a Neural Network to minimise the error, in real-time, so as to make the processor a trained CFP. (b) It is vital to this stage, and to this embodiment of the method generally, that the training set for step 2 has a fine-grid dataset of fire-models to use as a training baseline (the “baseline dataset”); this could be achieved by one of two ways: i. Run another 1,000 or so simulations at fine-grid level (same as the TVT dataset of step 1) and use that as the baseline; ii. Use the actual TVT dataset of step 1. We recommend using the TVT dataset of step 1, purely for reasons of practicality; the simulations already exist, and it will save significant time and money to re-use the TVT dataset for a different purpose than to create an entirely new set of simulations. The choice is the practitioner’s. (c) Whatever the source of the fine-grid baseline training dataset, what is important is that the (coarse-grid) FTRT models for step 2 use exactly the same fire-models (other than scaling factors, explained below) as the (fine-grid) baseline model dataset (whether that is the TVT dataset used for step 1, or a completely new set of baseline simulations), otherwise this embodiment of the method will fail. The only difference between the baseline dataset and the FTRT models of step 2 should be the scaling-up factors for the spatial-temporal mesh, i.e., the scaling up of the spatial grid size and I or the duration of the time-step; either or both can be scaled up for step 2, meaning the spatial grid-size could be scaled up and the time-step remain unchanged; or the spatial grid-size could remain unchanged, and the timestep could be scaled up. In terms of scaling-up factors, the choice is entirely down to the practitioner, the only stipulation being that it must be a choice which enables the computer processor to create the simulations in FTRT, otherwise there is no point to the method in the first place. (d) The CFP is trained to make the FTRT models as accurate as possible; this is achieved by running the FTRT models with the chosen scaled up spatial-temporal mesh, and comparing the simulated values of the simulated sensory data (as a simulated time-series) of the FTRT models at multiple simulated locations (we recommend 30 to 50 minimum). As previously stated, it is important that the simulated fire data for the simulated first location be included in the output of the FTRT models, but in preferred embodiments this data should be “set aside” for step 3 and not used as part of the training of step 2. The difference between the FTRT simulated sensory data time-series and those of the baseline dataset can be compared to create a loss function (in preferred embodiments, using the R2 method described above, noting that alternatives are possible), which can then be minimised by, purely as an example, applying SGD to a Neural Network to create a trained FTRT modelling system. For the purposes of this method, it is important that the system uses a TVT split for this sub-step of step 2. The next part of this sub-step (d) would to be run first for the validation dataset, then for the test dataset as is standard practice; we recommend that 80% of the baseline dataset be used for training the CFP to make accurate FTRT models, and then 10% of the dataset is used for validation, and 10% for test; however, this split could vary depending on some routine experimentation, the specification of the processors etc and this is left to the skilled practitioner to decide. Step 3: Once the CFP is trained to be an accurate FTRT modelling system, the final stage is the “true-up, true-down” stage, and this is where the training stage of step 3 differs from that of steps 1 or 2. For this step 3, we are training the system to create FTRT fire-models, and then adapt them in real-time (by altering weights or biases contained within the hidden layers of the data) as if in reaction to real IOT sensory data from a real fire, except in the case of step 3 we are using simulated IOT sensory data from a simulated fire. The fire models, and the simulated fire data relating to the one or more simulated first locations associated with those fires, should be the fire-models from the baseline data set (either of the TVT dataset used by the method of step 1, already disclosed, or a new set of baseline (fine-grid) simulations; for ease of reference, we will assume the use of the TVT dataset hereinafter, but the method would be exactly the same if a new set of baseline simulations was created). In order to validate and test the CFP’s ability to make accurate FTRT fire-models and then “true-up, true-down”, we follow this method now disclosed: (a) We send to the CFP simulated fire data from one or more simulated first locations (the location of the simulated IOT sensors in the digital twin). Only simulated fire data from the first location should be used. i. Such simulated fire data should be from the baseline dataset of step 2 (which may also be the baseline set of step 1, but need not be). ii. The simulated fire data from the baseline models (of step 2) should be compared to the simulated fire data from the FTRT models (of step 2). An automated script would need to be coded in order to do this. (b) Once the CFP makes the above comparison, it adjusts the weights or biases of the FTRT models, and this causes the FTRT models to change accordingly in the simulated present, or as close to the simulated present as is computationally possible, so that the FTRT model is continually adjusted in simulated real-time using simulated “actuals”. (c) There are two main methods for adjusting the weights or biases of process (b) of this step 3: the “stop-start” method and the “continuous method”; each will now be explained in turn. The simulated fire data of the baseline model is intended to act as a surrogate for real fire data from a real fire; for this reason, it must be presented to the CFP in “real-time”; it is best to illustrate this concept using a worked example, and certain assumptions. Let us assume that the time-step for the FTRT simulation is 0.01 seconds, and the sim-time of the simulation is 30 minutes, which in reality means that the simulation contains 180,000 time-steps. Let us further assume that the run-time of the FTRT model is 6 minutes, meaning that the FTRT model is running 5 x FTRT (3016). What this means is that for every second of “real-time” corresponding to the simulation (and bearing in mind, in a real fire for which this step 3 is being prepared, the real fire data will be received in real time, which will bear no relation to run-time and, in this example, will be five times slower than the sim-time), in this example 100 time-steps will have been executed (i.e., 100 calculations of all required equations for all spatial cells). We need to map the correct fire data, as it would be received, to the correct FTRT time-step, to make a meaningful comparison. In the method of step 3, the “real” fire data is being proxied by the baseline fire data, which is more accurate than the FTRT data. For example, if the comparison of the data was to be made after 10 seconds of real-time had elapsed, this would equate (in our example) to the comparing the baseline data to the FTRT data at time-step 1,000 (10 seconds = 1,000 x 0.01 s, the length of each time-step), for both models. If the next comparison was made after 30 seconds of real-time, then the baseline data would be need to be mapped to the FTRT data at time-step 3,000 (30 seconds = 3,000 x 0.01), for both models. Assuming that once we had reached 30 seconds of real-time, we then wish to update the FTRT models with (simulated) real-time fire data, we would then be mapping the baseline data to the FTRT data at time-step 3,100 (31 seconds), time-step 3,200 (32 seconds) and so on, always the same time-step for both models. The challenge which then arises is how to accommodate, within the FTRT model, the required changes (the required adjustments to the weights or biases of the FTRT models, which were constructed in step 2, based on the comparisons between the surrogate real data provided by the baseline models, and the less accurate predictions of the FTRT models). This has to be done in, or close to, real time, so that the FTRT models can be dynamically adjusted and the outputs of the models dynamically adjusted in turn. There are two main ways to achieve this (others can be created). i. The stop-start method: in this method, the comparison is made at the appropriate time-step (in our example, say timestep 1,000 which equates to 10 seconds of real time) and the FTRT model is stopped, the adjustments to weights or biases made, and the model starts again at (in this example) time-step 1,001 with a slightly different set of weights or biases than would have been the case if they had not been changed at time-step 1,000. It is necessary to “buffer” the incoming real fire data (or surrogate baseline data) in some form of storage, so as to enable the adjustments to be made and completed, before re-starting the FTRT model and ensuring a corresponding map of real-time, or surrogate, data to the correct FTRT time-step. The FTRT model will then run as normal until the next comparison (let us say at 30 seconds of real time, so timestep 3,000), and the model will be stopped by the CFP, adjustment to weights or biases made, and the model will restart at time-step 3,001 from a slightly different place. If we then continue to update and compare every 1 second of real-time, then we would repeat the process at time-step 3,100 (make appropriate changes, re-start at time-step 3,101), then time-step 3,200 and so on. Although this method requires a lot of “stopping and starting”, as the name suggests, it is the equivalent of the way a video works; a video is, in reality, a series of stopmotion frames which are run so fast that the human eye cannot separate them, and so the illusion of continuous motion is created. The stop-start method works the same way: due to the power of modem computer processors, especially in a cloud-based system where computing power is almost infinitely scalable, the delays caused by the intermittent stop-start process can be processed in fractions of a second, so that even if the cumulative effect in real-time is a delay of tens of seconds, or even a minute, towards the end of the run-time, such that the run-time was extended (in our example) from 6 to 7 minutes, or even 8 minutes, it would still leave 22 or 23 minutes time to anticipate the fire, and take appropriate action; the model would still be FTRT. ii. The continuous method: we can illustrate this method using the examples of time-mapping used in the description of the stop-start process. The continuous method differs from the stop-start process only in that the FTRT model is not stopped when the comparisons are made between the surrogate (or real) data, and the corresponding FTRT data, at the timestep which relates to the corresponding real time. In the continuous method, the FTRT model continues to execute while the adjustments to the weights or biases are implemented; clearly, since not all changes can be made simultaneously (even for a fast computer, there will be timelags even if they are in microseconds or milliseconds), the FTRT model will be updated almost continuously (hence the name), and it will be difficult to ensure that the correct realtime data (or surrogate data at the correct baseline time step) is mapped to the correct FTRT time-step. For this reason, it is necessary to “buffer” the incoming real time data (or surrogate baseline data) in some form of temporary storage, so that the comparison (and associated changes) associated with na later time-step are not made until all the changes of the previous comparison are updated in the FTRT models. In this way, the delay in the FTRT model caused by the continuous method tends to be largely manifested at the point of the first comparison, and remains fairly constant through the remainder of the run-time, as opposed to the stop-start method where the delay builds over time, as more stops are embedded in the FTRT models. The choice between methods is down to the speed of the processor and available RAM, and some routine experimentation may be required by the skilled practitioner to decide for a given computing platform; if possible, both methods should be trialled and the method which produces the fastest and most accurate convergence selected. (d) The process of part (b) (enabled by that of part (c)), runs continuously during the sim-time duration of the FTRT model, which could easily be longer than 30 minutes in advance, such that after the simulated time corresponding to the first adjustment has been past, the FTRT model will be updated every (simulated) second (as an example, but it could be every 5 seconds, or 10 seconds), in some way against a corresponding (simulated) actual. (e) The accuracy of the FTRT model (defined as a +1- variable percentage tolerance against an actual (simulated) sensory value, of a given type, at a given time) after the process of part (d) will be lower initially but, as the continual adjustments start to take effect, within a period of time the predictive FTRT model will converge to a steady-state level of accuracy at a given point in time, by means of the cumulative effect of the “true-up, true-down” method of processes (c) and (d). The period of the convergence time depends on the accuracy of the models, speed of the system and the level of detail of the digital twin data. (f) If the accuracy of the model as per part (e) is not enough, then more and more baseline and corresponding scaled-up FTRT simulations can be run, and the sub-steps (a) through (d) can be re-run until the desired level is achieved, or the law of diminishing returns sets in. The method of this step 3 is another inventive concept of this invention. Before proceeding to step 4, there is a need to address the issue of signal loss from IOT sensors, which will impact the accuracy of FTRT models; we call this protocol “PILOT”, which stands for “Protocol for Intermittent Loss Of Transmission”. PILOT: in a real fire, there is a high likelihood that at some point, the products of the fire (radiative heat, hot gas layer, smoke) could destroy the IOT sensors closest to the fire, causing them to cease transmitting fire data to the processor or compromising the accuracy or order of the fire data, thus removing the ability to check calculations involved in any of steps 1 to 3, and keep the accuracy of the FTRT models converged; electronic devices are sensitive to heat and often are not capable of working above an ambient temperature of 200°C, whereas temperatures in a building fire can reach or exceed 1,000°C. Additionally, the IOT sensor may lose contact with the computer processor for any number of reasons, if the connectivity with the platform is broken. There are now disclosed three main methods to combat the ambient heat problem, the first two being physical and the last being digital solutions: 1. Coat the external housing of the sensors in a thermally insulating material, or construct the housing from a thermally resistant substance: this is an effective idea and is simple to execute, but the problem is that it is quite expensive, cannot be implemented on sensors which have already been installed (so, will require replacement of the sensors initially), and at some point the temperature of the fire will still destroy any such sensor; 2. Place the sensors lower down in the room in which they are located; it is a known fact that the temperature close to the floor of a room in which a fire is ongoing is often less than 20% of the temperature at the ceiling level. This approach is the easiest physical approach, but smoke sensors in most countries legally have to be placed on the ceiling (heated smoke from a fire generally rises), so it requires another housing in which to place sensors; a solution would be to place sensors on the outside, or inside, of electrical sockets (usually placed close to the floor), which also has the benefit of detecting early warning signs of electrical fire. A drawback of the system is that this requires many new sensors to implement, adding to the cost of the solution considerably. 3. A digital approach is to train the processor to extrapolate a predictive fire-model, in the event of signal loss from an IOT sensor, and this is the core PILOT concept. An overview of the method is provided. The PILOT method would be best executed as a sub-method within step 3, although it is deserving of special mention because it is a self-contained method and is inventive in its own right; the PILOT method can be executed without having to also execute the method of step 3; equally, the method of step 3 can be executed without the POLIT sub-method; the preferred embodiment of the method has them both being executed in parallel. The PILOT method uses mathematical techniques of approximation theory, numerical analysis and statistics; as stated, it is recommended that the PILOT method be executed as a sub-method within the step 3 method. The PILOT method requires a sub-method for predicting values of the sensory data in the event of signal loss, and training the processor to improve accuracy of its predictions in this regard. The prediction sub-method is a series of mathematical operations which can best be described as: • The Approximation stage, or alternatively the Interpolation stage; • The Extrapolation stage. To make the predictions in the first place, the processor needs to use the data it receives prior to signal loss, which it has already incorporated into the fire models; since signal loss can happen without warning at any time, the method of the system is that the PILOT protocol runs as a separate operation in the background, and is trained (using ML) as a separate function of the computer processor, such that in the event of sudden signal loss, the PILOT sub-method can immediately be called upon to function. The aim of the Approximation stage is to take the time series of values of all or any sensory data (examples include, but are not limited to, any of fire location, HRR, temperature, smoke, gases) which have been received, or in the case of step 2, simulated in the accurate baseline dataset, and approximate the relationships between the time-series values of a sensory data type of interest, against those of other sensory data types, and against underlying parameters of the fire such as HRR and location; this can be achieved by the processor applying techniques of Approximation theory. The main aim of Approximation theory is to express the relationships between the variables as a polynomial function of high degree. There are many techniques which could be used, including: generalised Fourier analysis; the use of orthogonal polynomials; Chebyshev polynomials; Clenshaw-Curtis Quadrature; Remez (or Remes) algorithms. Other methods of Approximation may be used. The Approximation stage can be replaced with an Interpolation stage, whereby the processor takes known values of data already sensed (or, in the case of step 3, already simulated in baseline models and presented to the processor as if the data was real). Techniques of Interpolation include: Piecewise constant methods, such as “nearest-neighbour” interpolation; other techniques of multi-variate interpolation such as n-linear, n-cubic, Kriging, inverse distance weighting; linear interpolation; Polynomial interpolation; Spline techniques; Memetic Interpolation; Gaussian processes; other interpolation methods may be used. The processor may use Approximation methods only, Interpolation methods only, or both methods in parallel, to create a “library” of constantly updated relationships between real (or surrogate real) data and I or underlying parameters such as HRR, fire location and also other real (or surrogate real) data. The advantage of this library is that it can act as an alternative generator predictions to those of step 2, to be updated by means of adjusting weights or biases, once the simulated real results are available to be compared to the predictions; thus, the PILOT method could be used as an extra check, or data source, for FTRT predictions in addition to, or in parallel, to CFD models. Once a valid approximation function has been calculated, the processor needs to be able to extrapolate the data and make predictions. Valid extrapolation methods would include: linear techniques; polynomial techniques; conic; French curve; geometric extrapolation with error prediction; Fast extrapolation; complex plane extrapolation, where the operation is transformed into interpolation by a change of variable to 1 / z; other methods may be used. The processor would then make predictions in the same way as the CFD models, and compare the results in the same way; as stated, in this sense, the PILOT sub-method could also serve as an alternative to the CFD models by acting as “an interpolation &extrapolation engine” for the processor, and the outputs of the predictions could be used to estimate the accuracy of the CFD simulations as well. Alternatively, the PILOT system could use a standard fire curve, such as the Cellulosic fire-curve ISO834, or other fire curves, of which there are many which would be known to the skilled practitioner, including but not limited to: the Hydrocarbon fire-curve; the Modified Hydrocarbon fire-curve; RABT ZTV fire-curves; the RWS fire-curves; the mathematical formulae for these curves are very well known and disseminated amongst skilled practitioners and widely referenced in fire-safety literature. These algorithms could be used by the PILOT system as an alternative to the detailed approximation I interpolation, extrapolation method already described; the method would be for the PILOT system to use one or more of the curves, or some average of a plurality of curves, to make temperature predictions at one or more given (simulated) future points of time, in parallel to the FTRT models and compare the simulated actual temperature values of the baseline datasets against those predicted values from the fire curves, and then apply adjustments to weights or biases of the factors and operations of the fire-curve algorithms as required. It is well known that the mathematical relationship between the heat of a fire and the temperature at a given location obeys an inverse square law; HRR can therefore be approximated from the fire-curve, by taking different temperature predictions, based on the one or more fire curves, from two closely grouped points in time and, based on the location of the fire (or using a random estimate of fire location, which could be updated in light of newly received real, or surrogate real, fire data), using a reverse inverse square law to derive an estimate of the heat levels corresponding to the two closely grouped points in time (for which the temperature was calculated), then subtracting the estimated heat value of the later point in time from that of the earlier point in time; this provides a reasonably reliable method for calculating heat released per unit time, which is the definition of HRR. Therefore, using fire-curves (and not sensory data), and known location of the fire we can estimate HRR and known locations of the fire, and model these and “true-up” or “true-down” in parallel to the FTRT dynamic process of main step 3, previously disclosed. The disadvantage of this method is that it is not as accurate as the FTRT CFD or zonal models; the advantage is that it does not rely on IOT sensory data, so it is an excellent means for implementing the PILOT sub-method, which is only intended for use when the IOT sensory data is lost anyway. The Approximation I Interpolation &Extrapolation method outlined previously could also be applied to the fire-curve algorithms described above, and this would likely prove to be a very fast mechanism for achieving a reasonably accurate alternative predictive method to the FTRT models; it would not be as accurate as the FTRT models, but it would be much, much faster and it would be an acceptable alternative to no fire-modelling at all (as would be the case if there was a loss of IOT sensory data); the basic purpose of the PILOT method. The PILOT system could be trained in a very similar way to the CFP of step 3, as follows: using the baseline dataset, as previously defined, the PILOT system could be trained to make predictions separate to the CFD FTRT models, using approximation, interpolation and extrapolation techniques and then compare them to real (or surrogate real) results for HRR, location, key sensory data etc, or alternatively using one or more standard fire-curves to estimate local temperature near the simulated IOT sensor; using a Neural Network, which may in this case be a Regression NN, the PILOT sub-system could then be trained by adjusting the weights or biases of the hidden layers which the RNN would construct within itself, and the same “true-up, true-down” techniques of the step 3 could be used to improve PILOT accuracy. Once new signals are re-acquired, the PILOT system can go “back into the processing background”, and keep functioning there until it is called on again; the CFP can be trained to “drop” and “pick up” the PILOT system by simulating signal loss during step 3 training, to see how the processor fares. The PILOT sub-method is another inventive concept of this invention. Step 4: The method of this step is identical to the method of steps 1 to 3, including the use of the PILOT protocol, except that the predictions of the FTRT models and I or PILOT sub-method will be compared to real corresponding actuals, and in this regard the estimation of HRR and fire location of step 1, the creation of FTRT fire models in step 2, the application of the dynamic method of step 3 (for both FTRT models and I or PILOT sub-method), to a real fire are all inventive concepts of the method of the invention. It is important to state that the definition of “fine-grid” versus “coarse-grid” will change overtime, as computational capabilities increase and the size of the grids reduces, in line with increased computational power. For this reason, although we recommend 5cm grids for fine-grid and 30cm grids for coarse-grid, it is expressly stated that any size grids can be used and that we expect, in the future, such grid sizes to reduce; what is important is that, as stated in the introduction to the invention, the 4-dimensional mesh of the baseline (fine-grid) models will always comprise smaller cells (spatial, temporal, both) than FTRT (coarse-grid) models. The computer-implemented method of the invention is typically performed in a Faster Than Real-Time (FTRT) computational predictive fire-modelling system, which may in embodiments be linked, for the purposes of one-way or two-way communication, to all or any of third-party fire protection and I or structure management and I or structure evacuation systems and wherein the data to be communicated relates to any of the disclosed outputs of the method, or any outputs which might reasonably be required by the skilled practitioner to implement any part of any of the method of the first aspect of the invention. As disclosed previously, the trained CFP could also be communicatively and operably linked to one or more automated fans or hoses, for the purposes of efficient and automated tactical ventilation or fire suppression; since the CFP will have access to FTRT CFD models, and since the modelling of air from the use of fans, or water from the use of hoses, is also CFD, then provided the CFP had access to information such as the throughput capacity of the fans, dimensions of the fan blades, applicable water pressure available to hoses, then it could optimise the deployment of such equipment, the locations and angles of attack, the timing of use etc, using basic geometry and CFD algorithms. The purpose of this invention is to apply the method of FTRR modelling (with some degree of processor training by means of machine learning) to a real fire; in this sense, the “fourth step” can be viewed as the aim of the invention rather than a step within the method. It is included as such herein only as a convenient means of illustrating a logical flow (from pre-trained processor to real fire), but it is important to state that the main idea of the invention is to pre-train a processor (by means of step 2 with options to include steps 1 or 3, to model real fires in FTRT). The only mandatory step of this aspect of the invention is the core step 2; since all other steps are recommended, but not mandatory, there exists 8 embodiments of possible methods of this invention, each of which provide a viable embodiment (of varying degrees of preference), of the method of this aspect of the invention: (1) Preferred Embodiment: The preferred embodiment is the method with the highest accuracy and still is FTRT; it has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to a verified level of accuracy to estimate the HRR and fire location using the method of step 1; • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to dynamically update the FTRT fire models with real fire data during the course of the fire and simulation, using the method of step 3; • a processor which is further pre-trained to create alternative predictions for the FTRT models using the PILOT sub-method of step 3, such that the FTRT models can continue even if the data transmission from the IOT sensor is lost, during the real fire. (2) First Less Preferred Embodiment: This first less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to a verified level of accuracy to estimate the HRR and fire location using the method of step 1; • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to dynamically update the FTRT fire models with real fire data during the course of the fire and simulation, using the main method of step 3 (i.e., without PILOT). (3) Second Less Preferred Embodiment: This second less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to a verified level of accuracy to estimate the HRR and fire location using the method of step 1; • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to create alternative predictions for the FTRT models using the PILOT sub-method of step 3, such that the FTRT models can continue even if the data transmission from the IOT sensor is lost, during the real fire. (4) Third Less Preferred Embodiment: This third less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to a verified level of accuracy to estimate the HRR and fire location using the method of step 1; • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; (5) Fourth Less Preferred Embodiment: This fourth less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to dynamically update the FTRT fire models with real fire data during the course of the fire and simulation, using the method of step 3; • a processor which is further pre-trained to create alternative predictions for the FTRT models using the PILOT sub-method of step 3, such that the FTRT models can continue even if the data transmission from the IOT sensor is lost, during the real fire. (6) Fifth Less Preferred Embodiment: This fifth less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to dynamically update the FTRT fire models with real fire data during the course of the fire and simulation, using the main method of step 3 (i.e., without PILOT). (7) Sixth Less Preferred Embodiment: This sixth less preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2; • a processor which is pre-trained to create alternative predictions for the FTRT models using the PILOT sub-method of step 3, such that the FTRT models can continue even if the data transmission from the IOT sensor is lost, during the real fire. (8) Least Preferred Embodiment: This least preferred (but viable) embodiment has the following characteristics in the event of the processor receiving real fire data from a real fire within, or on, the structure: • a processor which is pre-trained to create FTRT fire models to a verified level of accuracy using the method of step 2. All the above embodiments are viable, in the sense that even the least preferred embodiment is better than no embodiment at all. In accordance with a second aspect of the invention there is provided a computer readable medium comprising executable instructions that when executed by a computer cause the computer to perform the method of the first aspect of the invention disclosed above. In accordance with a third aspect of the invention there is provided a system for Faster Than Real-Time (FTRT) predictive computational fire-modelling, comprising: a High-Performance Computer (HPC) equipped with one or more communications devices and the ability to access and write to a large amount of stored computer memory; CFD software code or zonal fire-modelling software code; and Machine Learning (ML) and I or Artificial Intelligence (Al) software code and associated logical structures; to implement the method of the first aspect of the invention. An example of such a system is disclosed below, noting that many alternative systems are possible, as means of implementing the method of the first aspect of the invention, and would be well known to a skilled practitioner. The HPC may be a physical system, or a cloud-based system capable of simulating a physical computing system, or a hybrid of both types of computer. In preferred embodiments, the HPC is a cloud-based system comprising one or more Virtual Machines (VMs), each comprising one or more Virtual Central Processing Units (VCPUs), Virtual Random Access Memory (VRAM). The HPC will, for the purposes of executing the third step of the first aspect of the invention (receiving actual data from a real fire), preferably be connected to an Internet Of Things (IOT) cloud-based platform, with the ability to ingest IOT data in an industry-standard format, including but not limited to: XMPP; MQTT; CoAP; OPC UA; this is not an exhaustive list. For security purposes the IOT devices relaying sensory data from a fire would preferably be encrypted within a secure peer-to-peer mesh network, preferably by the use of a Virtual Private Network (VPN); in the foregoing example, the IOT devices would be each connected to each other, any other necessary remote devices within the structure in which they are located, and with the HPC itself by means of Public Communications network (wired or wireless), or satellite communications, using radio or alternative methods such as laser, infrared or any other transmission means equivalent to radio. The IOT sensors may also be configured to transmit sensory data using a proprietary IOT signalling method, and the HPC would be configured to ingest the data in proprietary format, to execute the third step of the first aspect of the invention; or the HPC may be configured to ingest both industry-standard or proprietary IOT signals containing sensory data from the fire. The HPC, in the preferred embodiment, could have any number of specifications because cloud-based VMs come in many different configurations and can be clustered to run together to form parallel “super-computers” acting as one (through the use of techniques such as multi-threading or hyper-threading); an example of a good specification would be a VM with a significant number of VCPUs (either with or without multi-threading), of between 48 and 196 VCPUs, and equipped with between 144GB and 640GB of RAM, combined with between 1TB and 2TB of storage. The HPC would be configured to communicate, one-way or two-way, with a large storage system containing a computer memory (hereinafter, the “first memory”), in which resides all the data relating to the digital twin of the building, and all the data which relates to the TVT datasets, the baseline datasets, the FTRT models, the history of all the simulations and data relating thereto including all data sufficient to implement the PILOT sub-method described previously, in order to execute any part of the first aspect of the invention. The memory storage system would, in preferred embodiments, be configured with a fully updated redundant memory, containing an exact real-time duplicate of the first memory, but stored logically separate to the first memory, such that in the event of a loss of communication between the HPC and the first memory, the HPC could access one or more instances of redundant memory to continue to execute the first aspect of the invention with minimal downtime. The system would, in preferred embodiments, be configured such that two or more HPCs would run simultaneously in the event of a real fire being detected at or in the structure (i.e., a situation in which is invoked the third step of the first aspect of the invention), such that one or more HPCs act as a “hot spare” system, in either of active-passive or active-active modes, ready to pick up the computing load of the first HPC should the first HPC fail to work, or communication with it is lost. Examples of the above preferred cloud-based HPC embodiment includes the Microsoft® Azure Cloud or the Amazon Web Services® Cloud, including associated storage, and specific examples of appropriate VMs (noting that there are alternatives) include the Azure family of HBV or F72 series VMs. CFD code to run on the HPC may be self-coded by the skilled practitioner, but in preferred embodiments the CFD code would be one of the generally available CFD commercial software packages, examples of which include: Fire Dynamic Simulator® (FDS), OpenFOAM®, PyFOAM®, Ansys®, Comsol®, Fluent®, CRISP, JASMINE, SOFIE; this is by no means an exhaustive list. Machine Learning and I or Al code, and associated tools and logical structures such as Neural Networks (or equivalent) and error minimisation algorithms, could be self-coded by the skilled practitioner, but in preferred embodiments the ML and Al tools would be those which are commercially available, examples of which include: Microsoft® Azure Machine Learning; Microsoft® Azure Al Platform; Amazon SageMaker®; Amazon Al services; Amazon Bedrock®; Jupyterlab; this is by no means an exhaustive list. The PILOT method could be developed by the skilled practitioner using any of the commonly available mathematical tools for numerical analysis, approximation techniques, interpolation and extrapolation techniques, which would be embedded in the cloud-based HPC by means of automation tools and sub-routines, and configured to reside in, or be in communication with, the first and any redundant memories. It is outside the scope of this invention to specify the type of sensor which may be used to collect real sensory data from a fire, (other than to list the type of data which may be used, as per the section disclosed earlier on Real-Time Sensory Information), but it is clear that any suitably configured system according to this third aspect of the invention could include information on any of: heat levels (such as may be captured by contactless or direct-contact methods of heat measurement, such as contactless infra-red, or thermocouple); gas detection (using any of the established techniques of single or multi-molecular detection); smoke detection; airflow detection. Such sensors could include those which are pre-installed in the structure, or carried by firefighters or drones (or equivalent) and which could include, for example, Thermal Imaging Cameras (TICs) carried by said responsible agents. The FTRT predictive computational fire-modelling system described above may include any of the preferred features, or execute any of the methods, discussed above in relation to the first, second or third aspects of the invention. Brief Description of Drawings: We now explain the drawings which show principle concepts of the method and I or system, purely by way of example, noting that alternatives are perfectly possible. The drawings illustrate various embodiments of key aspects of the method and I or system of the invention, using the example of fire-modelling within a built structure. This is purely by way of example; the illustrations could just as easily be applied to FTRT modelling of other phenomena (e.g., HVAC energy optimisation, bio-aerosol threats, unified platforms for fire-modelling and HVAC energy optimisation, wildfires, atmospheric events etc) and the only difference would be to the type of sensory data and, therefore, to the type of sensor used; the sensory data could be macroscopic (e.g., thermal, optical, radio or radar images of large areas of terrain or space) or microscopic (IOT sensors, fixed or portable or mounted on a vehicle etc); the modelling software would also be different (instead of using fire-modelling software, air-modelling or plasmamodelling software would be used, depending on the phenomena being modelled). Figure 1 illustrates an example of the pre-training stage, using 8 key steps in the process (other combinations are possible, and would be appropriately adjusted by an expert in the field). Figure 2 illustrates a more detailed breakdown of the three key steps of the first aspect of the method of the invention (parameter inversion, FTRT modelling, convergence), but the stages numbers relate to those of Figure 1 (so stages 1 to 3 of the first aspect of the invention are stages 5 to 7 of the 8-step exemplary process of Figure 1). It shows how simulated sensory data is used to train the processor in parameter inversion, then using the simulated data in the FTRT stage, then using real (or simulated) data in the convergence stage. It is important to note that for pre-training purposes, all 3 stages would use simulated sensory data from baseline and I or FTRT models, in order to train the system using simulated drills. Figure 3 illustrates some examples of specifications for models for both input and output for the parameter inversion process; routine experimentation may be required depending on the phenomena and variables being sensed. Notice that the mesh size (or if meshless, the node density) is the same for the inputs and outputs of the parameter inversion stage. Figure 4 illustrates the process of creating the TVT database for the parameter inversion stage. The important aspect is to ensure that the outputs of the TVT database for parameter inversion is the same as that which would be detected by real sensors. Figure 5 illustrates the process of training the parameter inversion stage using the outputs of the TVT database models as inputs to the neural network, with the target output being the underlying modelling parameters which were originally used as the inputs in the example of Figures 3 and I or 4. Figure 6 illustrates some examples of specifications for models for both input and output for the FTRT modelling process; routine experimentation may be required depending on the phenomena and variables being sensed. Figure 7 illustrates the process of creating the TVT database for the FTRT modelling stage. The important aspect is to ensure that the mesh size (whether uniform or non-uniform) or, if meshless, the node density, is not the same; the mesh for the Fine-Grid models must be smaller than that of the Coarse-Grid models, and if meshless the node density of the STRT training models must be higher than that of the FTRT models. The size of the mesh, or the density of nodes, is down to the power of the computational resources (which will likely increase through time and dependent on the budget size), therefore this will vary depending on budget and compute power and cannot be determined in advance; the point is that the preferred method is to use an STRT model and a corresponding FTRT model, and what will constitute STRT and FTRT will depend on the power and budget of the user. The point is, whatever is STRT and FTRT for a given budget and technological resource will vary and must be determined by the each user; the metrics we have used (5cm grid for Fine-Grid, 30cm grid for Coarse-Grid) are metrics which have been validated, but over time it is possible that these metrics could change (i.e. there will come a time when a 10cm grid will be possible to run in FTRT, and if that happens that is what we would recommend). To summarise: the recommended method is to use the largest grid (or lowest node density) possible to make the STRT models STRT, and the smallest grid (or highest node density) to make the FTRT models FTRT. It is possible to train an FTRT model using an FTRT baseline (or a baseline that is not STRT), but it is not recommended because the purpose of using the fastest possible STRT model as a baseline is to make the baseline as accurate as possible. Figure 8 illustrates the process of training the FTRT modelling stage using the outputs of the TVT database models as inputs to the neural network, with the target output being the underlying modelling parameters which were originally used as the inputs in the example of Figures 6 and I or 7. Figure 9 illustrates the concept of convergence; this diagram is not intended to be a prescriptive drawing of how convergence looks, it is purely a schematic to provide a visual representation of how the concept works; over time, predictions are made by the FTRT models of the value of key variables (sensory data), at specific points in space (being where the sensors actually are in the physical twin) and at a given future point in time, and these are then compared with the actual results for that location and time, in order to establish a “loss function” between the prediction and the reality, to enable the neural network to adjust weights and biases within the hidden layers, so as to improve accuracy in real time. Figure 10 illustrates a detailed example of how convergence works; for example, the processor makes a prediction of a variable at a given set of points in time (say T+30, T+90, T+120 seconds etc) at a given location, and then the “ground-truth” from the real sensors (or simulated ground truth in the case of a simulated live drill) is used to update the models via the neural network. Figure 11 illustrates a schematic of how the overall convergence concept would work, as a flowchart. A prediction is made by the system, the actual result is ingested by the system and the two are compared, then information on that difference is fed back to either (or both) of the neural networks for parameter inversion or FTRT modelling, in order to adjust the weights and biases of the hidden layers. These adjustments are made, then the FTRT models are updated and produce further predictions, which are then incorporated into the feedback loop and so the process goes round and round, until the accuracy “converges” to a stabilised value of (preferably) +1-15%. Figure 12 illustrates the conceptual overview of the invention, and its main components; it is not intended to be a detailed precision document, rather a “mindmap” representation of the invention, to help the skilled practitioner visualise the system and method in order to implement it; Figure 13 illustrates the concept of creating TVT datasets and FTRT CFD fire-models, within a digital twin of a building compartment, which comprises two doorways. An IOT Sensor is shown, located off-centre in the compartment, located on the ceiling. Other types and locations of sensors are possible, e.g., as per Figure 3 below. This diagram uses a uniform CFD mesh, purely by way of example, but the principles would be the same for a non-uniform mesh or a meshless solution involving higher node density in place of a Fine-Grid model amd lower node density in place of a Coarse-Grid model. The two different spatial meshes of grid-size (Fine-Grid and Coarse-Grid) are also shown, with the Coarse-Grid being 3 times the scale of the Fine-Grid (purely as an example). The concept is to run TVT datasets (for step 1) and baseline data sets (for step 2, wherein these baseline datasets can be those used for step 1, or a completely new set of datasets). What is important is that the fires are simulated in the same compartment, using all the same fire-parameters and the same physical characteristics, including but not limited to compartment dimensions, doorway location and dimensions, whether the doorways are open or closed, combustibles, but using first the Fine-Grid spatial mesh (and appropriate associated time-step) and then a scaled-up Coarse-Grid mesh (with time-step, which may or may not be scaled up, as previously described). Figure 14 illustrates an exemplary FTRT predictive computational fire-modelling systems according to embodiments of the invention in a single occupancy building (as previously defined in terms of a network); this diagram essentially illustrates the preferred system embodiment of step 4 of the method (because all the components of this system are real), wherein real fire data from real sensors would generate real fire-models, sent to real remote devices. In these diagrams, the computer processor 500 (being one or more virtual machines) resides in a secure cloud platform 601 which has access to the building digital twin in a stored memory (not shown), wherein the processor is a CFP and is trained to create accurate FTRT fire-models, and which is linked by means of an encrypted VPN to the devices for sending inputs (IOT sensors) to the fire-models, and the remote devices 700 (smartphone) and 701 (laptop), for receiving the outputs of the fire-models. In terms of the input devices, the IOT sensors shown (100) come in three housing variants, being a ceiling-mounted sensor, a sensor housed in a light-switch, and a sensor housed inside an electrical socket; there is also a separate local hub (400), which in embodiments is most likely to be a Wi-Fi router for connecting to the internet, and thence to the cloud platform 601. The router 400 may, in some embodiments, be housed inside one of the sensors 100 (usually, the ceiling mounted sensor), but this is not strictly necessary. A failover connection between sensors and the cloud, in the event of a loss of connectivity between the sensors and the hub 400, or between the hub 400 and the cloud 601, is also shown. Other Aspects of the Invention: In a fourth aspect of the invention is disclosed a method involving the application of any of the embodiments of the method of the first aspect, and I or the computer readable medium of the second aspect, and I or the system of the third aspect of the invention to the modelling of Indoor Air Quality (IAQ) within a built structure (“built structure” being as defined in the preamble to this description), with appropriate adjustments to any of the aspects referred to in the foregoing. This fourth aspect of the invention would be the application of any part of any of the first, second, or third disclosed aspects of this invention to non-fire scenarios, especially using CFD applications involving the movement of air. Such applications include those wherein the CFD modelling relates to the movement of air (i.e., a non-fire fluid) and other non-fire atmospheric gases through or within a built structure, using the same concepts outlined above. Non-fire CFD applications of any of the other aspects of this invention for the built environment include multiple scenarios; such scenarios might include, for example, modelling in FTRT the movement of air caused by HVAC (Heating, Ventilation and Air-Conditioning) equipment and ducts installed or constructed within a built structure; research4 shows that FTRT modelling of multi-parameter IAQ variables (in the research it was ambient levels of temperature, carbon dioxide, and humidity) can reduce HVAC energy usage by up to 35%, providing a potential significant commercial benefit to the building user, and also reducing the carbon footprint of the HVAC system substantially. Other benefits might have important implications for the health of occupants of a structure, for example in a scenario where it is necessary to model, within the structure, the spread of air-borne pathogens, threats or bio-aerosols (e.g., including but not limited to viruses, bacteria, mould, fungi, harmful pollen, toxic gases or nerve-agents released as part of an attack on the structure etc). Parts of the 4-step process could be adapted and used to predict the flow of air in FTRT, before said airflow actually occurred, and the related sensory information would come not from IOT fire-sensors, but instead from IOT IAQ sensors, or sensors for detecting the conditions and composition of the ambient atmosphere (for example, ambient air temperature, carbon dioxide levels, humidity, oxygen levels, airflow velocity, volatile organic compounds etc), or pathogen, toxic gas or nerve-agent detectors deployed inside the structure, or could come from an alert by a user, or automated system, to the presence of any of such airborne threats. For HVAC energy optimisation, the method of the first aspect of the invention would require modification, as follows: parameter inversion would involve pre-training a model to simulate airflow from an HVAC system in a building, wherein the simulated sensory output is any or all of temperature, carbon dioxide, and humidity, purely by way of example) and this sensory data is mapped back to the underlying CFD modelling parameter inputs using a neural network (or equivalent), as per step 1 of the first aspect; the method of step 2 would be required, in that baseline (fine-grid) models would be required, and then FTRT (coarse-grid) models would be created which would be identical save for scaling of the 4-dimensional mesh (or scaling of a meshless solution by means of appropriate reductions in node density), and the Neural Network (or equivalent) would still be required for training, validation and test; step 3, although optional, would be highly recommended so as to ensure that the FTRT models are as accurate as possible, in order to achieve the optimal balance between occupant comfort and energy efficiency. For IAQ threats, e.g. in the event of an airborne threat incident, wherein a virus or nerve agent, or some other airborne threat, were released inside a built structure, the same 3 steps of parameter inversion, FTRT modelling and convergence would preferably be used to model the basic bulk movement of the air (advection), in addition to the need to model diffusion (see below) The CFD models would also require additional algorithms to model diffusion; diffusion (the spread of a gas or particulate cloud within a bulk fluid) is separate from that of advection (the movement of a bulk fluid itself, in this case air, which provides the transport mechanism for the diffusing substance); thus, there are two processes to be modelled simultaneously - diffusion and advection. Advection is modelled by CFD, whereas diffusion is modelled separately; that said, there are many of the commercial CFD packages available which have diffusion “add-on” components to model diffusion; if the option to self-code was taken, then the algorithms which would assist in diffusion modelling include: random walks, Monte Carlo methods, other Markov processes such as Markov chains, the diffusion equation, the convection-diffusion equation, Fick’s law and others which would be well known to the skilled practitioner. The outputs of the airflow models from the processor could be linked to a management system or environmental system of a structure, for one-way or two way communication; responses could include one or more automatic actions from any suitably configured equipment or remote device or system, or alerts to a remote device advising a user to take one or more actions, wherein any such actions might include any of: shutting down or re-routing some aspects of the HVAC air-flow, or ventilation of portions of the building (including but not limited to opening or closing windows, doors, ducts) and the activation, de-activation or orientation of adjustable particulate or gas filters. One of the advantages of the method of the first aspect, applied to this fourth aspect, over the prior art (including the research4 itself) is that the prior art seeks to minimise the computational intensity and run-time by reducing the dimensions of the data to “manageable levels”, in other words, sacrificing accuracy and granularity of data; this might be acceptable in non-threat scenarios, but it would not be acceptable in IAQ or threat scenarios - for instance, one simply cannot accurately model a fire (or a bio-aerosol) using average temperature (or pollutant) fields for a volume of space; granular data is required and this is granularity is completely preserved by the method and system of this invention, without sacrificing performance in terms of speed. In a fifth aspect of the invention is disclosed a method involving the application of any of the embodiments of the method of the first aspect of the invention, and I or the computer readable medium of the second aspect, and / or the system of the third aspect, in combination with any of the fourth aspect of the invention, to create a unified, single, pre-trained platform (a “hybrid”) configured to monitor and model (in FTRT) and in relation to a built structure, the IAQ to optimise the HVAC energy usage of the structure and either, or both, of the threat posed by fire, and I or the threat posed by a bio-aerosol or airborne pathogen, within said built structure, with appropriate adjustments to any of the aspects referred to in the foregoing. This fifth aspect therefore delivers a method and system for optimising HVAC energy usage through FTRT modelling as per the fourth aspect, in conjunction with either, or both, of a method and system for creating FTRT predictive fire models using the any or all of the first three aspects of the invention and a method and system for FTRT predictive modelling of an IAQ threat, using a network of sensors combined with the over-arching three-step process of the first and fourth aspects of the inventions on one computer processing platform. The sensors for the IAQ modelling for HVAC energy optimisation (typically, any of ambient levels of temperature, carbon dioxide, humidity) could be housed separately from those used for fire (any of the fire sensors from the first aspect, for example ambient temperature, carbon dioxide, humidity, smoke and I or any of the toxic gases mentioned earlier), and if combined with IAQ threats there could be separate sensors for airborne pathogens. However, a cursory glance at the foregoing paragraph makes it clear that there is sufficient commonality (especially in the case of HVAC energy optimisation and fire) in the variables being measured to include a basic range of the required sensors within one housing, to serve multiple simultaneous purposes. For example, one set of sensors which captured (as an example only) ambient temperature, carbon dioxide levels, humidity and smoke could be used to detect non-emergency levels, i.e., when there is no fire or IAQ threat, of all or any of the first three variables for HVAC energy optimisation purposes, while combined with smoke (and the higher levels of heat and carbon dioxide associated with a nearby fire, compared to a non-fire scenario such as for HVAC energy optimisation) these same sensors could detect the presence and properties of a fire, should one occur. Changes might need to be made to a preferred system embodiment of this method; for example, it might make sense to ensure some kind of thermal protection (thermal survivability) for the sensor housing to ensure that it operates as long as possible during a nearby fire, whereas obviously this is not a requirement for a non-emergency purpose such as HVAC energy optimisation. Temperature detection methods might involve any of thermal imaging, or thermocouple, or a thermowell from or in the sensor used to detect the temperature of the fluid (in this case, the surrounding air itself) into which it is inserted; in preferred embodiments, a thermowell or high-temperature thermometer would be most suitable, an example of a thermowell being and Endress &Hauser iTherm FlameLine TAF12S which can measure fluid temperatures from 0°C to 1,600°C (the upper range here is much higher than would be needed, which would typically be between 200°C and 500°C); many alternative devices are available and routine experimentation would be required to decide the best combination of performance and cost. Thus, a set of sensors could be commonly housed for two simultaneous purposes, as follows: any of ambient heat, carbon dioxide levels, humidity, to detect the environment to model FTRT HVAC energy optimisation, in a non-emergency situation, and to “switch over” to monitoring the same three variables plus that of smoke to create predictive FTRT models of a fire in a fire emergency situation. Since the FTRT modelling method and system is the same for both, and the sensors could be housed together, this makes for a very powerful unified platform for IAQ and Fire detection, monitoring and FTRT modelling. It would simply be necessary to select heat or temperature sensors which could cover the range of everyday ambient temperatures (for HVAC purposes, “room temperature” ranges) right up to much higher temperatures associated with those near a fire (hundreds of degrees Celsius), and the same principle would apply to carbon dioxide levels. IAQ threats could easily be incorporated into the above unified method or system, by placing selected airborne pathogen detectors inside the housing as well. One digital infrastructure (the digital twin, network, cloud, compute and memory etc) could then be used to deliver multiple valuable services in a way cost-effective way. Although the modelling in FTRT of fire, IAQ (bio-aerosol threats) and HVAC optimisation are presented elsewhere as three separate inventive aspects, and therefore three separate inventions, the fact that all can be addressed from one, unified set of sensors and common computing platform is, of itself, an inventive concept by means of creating a method and system which simultaneously addresses safety, carbon footprint and combined cost-savings; therefore this aspect, the unification of other separate aspects, does not give rise to a plurality of inventions but is an invention in and of its own right, meriting disclosure. In a sixth aspect of the invention is disclosed a method involving the application of any of the embodiments of the method of the first aspect of the invention, and I or the computer readable medium of the second aspect, and / or the system of the third aspect to a wildfire, as opposed to a fire within a built structure, with appropriate adjustments to any of the aspects referred to in the foregoing. A wildfire is defined as a fire in an open space, sparsely inhabited or uninhabited, and wherein the majority of the combustible source is vegetation (trees, bushes, shrubs, grasses, heather as examples). In such a situation, any of the methods or system of any of the first, second, third or other aspects could be applied as disclosed, without modification to any of these disclosures, save for appropriate changes to the grid-size, volume of space to be modelled and basis of calculation of the same. Such changes relate to the size of the grid, which typically would be 50cm3; the height of the space to be modelled (there being no compartment to define a height) would be the average height of the vegetation which could be estimated or assumed, based on surveys. Assuming an average height of 12 metres, then if the 50cm3 CFD grid-size were chosen as the Fine-Grid (equivalent of the 5cm3 grid of the built environment), and given that an average compartment is 125 cubic metres, giving approximately 1,000,000 cells in the 5cm3 Fine-Grid built environment model, and this were to be translated to a 1,000,000 cell modelled space consisting of 50cm3 cells, this would translate to a surface area of some 42,000 square metres (being 1,000,000 divided by the average height of the vegetation, in this worked example 12, for 12 metres which equals 12x1 metre height cells). Larger surface areas of vegetation could be modelled by combining multiple 42,000 square metre areas in a form of “digital patchwork” mechanism. Or, larger than 1,000,000 cells per model could be modelled (there being no particular limit at the 1,000,000 cell level; this value was chosen only to translate directly, allowing for scale changes, to the example of a building compartment, but there is no other significance to the 1,000,000 cell number per model). The FTRT Coarse-Grid equivalent would then consist of 1,5m3 cells; again, purely by way of example, and this would also satisfy the “rule of 8” in the height axis. The additional data for a wildfire, for example the equivalent to the digital twin of the building, would be a digital twin of the open space to be modelled for a fire; this could come from a digital twin of a relief, or contour, map, which would show changes to height and elevation; it could show steepness of slopes, using a contour map. Such maps are widely available, and also could be enhanced by a more thorough survey of an area of open space, or forest, to be protected by the method or system of this invention. Other information on combustibles could come from observations, or assumptions, on the types of vegetation (for example, different types of tree-wood have different ignition and heat-release rate characteristics), the average distance between the vegetation (for example, the average distance between trees in a forest, or an assumption of a contiguous expanse of vegetation for low bush or grasses). Sensory data would likely not come from pre-installed sensors, although preinstalled sensors (including any of heat, smoke, airflow, carbon dioxide or monoxide) could be deployed, it is likely that the sensory information would be of the macro type, i.e., thermal images. In the case of wildfires, thermal images could come from handheld or portable, mounted devices, suitably equipped drones or other flying vehicles, or even satellite images; such images could be processed by methods and tools of thermal imaging and computer vision into sensory data which would be capable of being processed by the computer processor, and incorporated into the fire models of any aspect of this invention, and such techniques would be well known to a skilled practitioner working the invention. Other sensory information which could be made available would be meteorological data, such as short-term weather forecasts, especially regarding wind velocity and precipitation, which could be sent to the computer processor via a link from a third-party meteorological database or prediction system. This sensory information could then be applied to the “true-up, true-down” process, applied to the FTRT models which would be created in the manner described in the method of the first aspect of the invention, albeit on a much different scale adapted as disclosed in this other aspect. Another feature of the wildfire method or system is linking the CFP to large automated fans or fire hoses, which may be vehicle (land, sea, air) mounted, or ground-mounted, and enabling the CFP to direct tactical ventilation or fire suppression or movement activities by referring to the latest predictive models of the fire (e.g., to change the predicted path of the fire, or delay its spread). In a seventh aspect of the invention is disclosed a method involving the application of any of the embodiments of the method of the first aspect, and I or the computer readable medium of the second aspect, and I or the system of the third aspect of the invention to atmospheric events, primarily ionospheric or geomagnetic atmospheric events, or tropospheric events such as hurricanes, storms and typhoons, with appropriate adjustments to all the aspects referred to in the foregoing. Research5 indicates 11 main types of Ionospheric or Geomagnetic Disturbance (or IGD) which can affect multiple different uses and cases of radio communication and radar detection; the ability to model these IGDs in FTRT would give valuable information to interested parties in relation to how badly affected, for how long, and where, radio I radar would be affected by said IGDs and enable said parties to adopt mitigating strategies to cope, enhanced by the predictive power of the method and system. The research5 lists 11 main types of IGD which could be modelled by this aspect of the invention, but it should be noted that other phenomena could equally be modelled using the method of this aspect of the invention, so the following list is not exhaustive: 1. Short-wave fadeout I blackout from a solar flare; 2. Short-wave fadeout I blackout from Relativistic Electron Precipitation; 3. Solar radio Burts; 4. Polar cap absorption; 5. Auroral disturbances; 6. Ionospheric positive storm; 7. Ionospheric negative storm; 8. Travelling Ionospheric Disturbances; 9. Equatorial Plasma Bubbles; 10. Sporadic-Es; 11. Polar patches. The above IGDs can be modelled in FTRT using this aspect of the invention by using the same 3-stage process as shown in Figure 2. It is important to follow the three-stage process: parameter inversion, FTRT modelling, and convergence. It is worth re-stating the important when building PI TVT dataset, we ensure that the models we create include outputs that are identical to what the real world sensory data would show, so we need to know what a real IGD detection system might see, in order to train the system on the PI aspects of the method but applied to IGDs. Such sensory data would be well known to skilled practitioners, and example of this data could include terrestrial measurement methods such as radar, ionosonde (digital or analogue), outputs of an ionogram, estimates of total electron content, electron density gradients, electron and ion temperature, ionic composition, gradient drift instability, thermal or optical images, and also satellite observations of all the same; such data could also include oxidative re-combination in the 135.6 nm range (so called "nightglow" or “airglow”, of which there are many wavelengths); and other equivalent measurement methods, as determined by experts in the field. The point is that the baseline models for parameter training would need to be configured to create outputs in the same format as the target sensory data per the foregoing in order to be able to pre-train the processor to perform the parameter inversion process accurately, and get back to the underlying modelling parameters. This means the practitioner must decide what sensory data will be used to detect the IGD before configuring the models for parameter inversion. The CFD software tools used for modelling IGDs in the parameter inversion and FTRT modelling stages will differ from those of previous aspects, largely due to the influence of electrical and magnetic phenomena on the fluid-dynamic properties. Well known examples of such tools are those used for Computational Magnetohydrodynamics (CMHD) and I or Computational Electrohydrodynamics (CEHD), of which many variants exist, or which can be created from scratch using Navier-Stokes and Maxwell equations. In terms of implementing a system using this method and these tools, examples could include tools such as BATSRUS (a block adaptive mesh tool developed by the University of Michigan), the NASA GOLD satellite system, and CMHD and CEHD tools from Comsol. In terms of detection tools, digital ionosondes such as those provided by Lowell, or other radio astronomy services, could be used. Given the sheer size of the ionosphere and the size of the digital twin necessary to model it, and the relatively small size of IGDs in relation to this, it is recommended that an adaptive (non-uniform) mesh be used, to save computational resources on large areas that would not be of interest in relation to the IGD. If a meshless model were used, then the node density of the areas of interest would be much higher than the other areas. For the second step of FTRT modelling, underlying modelling parameters used could include: total electron content, electron density gradients, gradient drift instability, collision and fission metrics (to build collisional and fissional models from the ground up, whereby collisional models simulate the reduction in free electrons from collisions of positive and negative ions, and fissional models simulate the increase in free electrons from the separation of neutral gaseous atoms into free positive and negative ions, by the injection of energy from the sun or earth), simulation of Rayliegh-Taylor instabilities, and the use of Gaussian models or other models well known to experts in the field. The choice of modelling parameters will be influenced partly by the intended detection methods (for use in parameter inversion), and also by the choice of CM HD and I or CEHD code used (if using an “off-the-shelf” or software toolkit). The modelling could be used to take into account the impact of solar processes on the ionosphere, such as Extreme Ultra-Violet (EUV) radiation in the E and F region of the ionosphere, the impact of Relativistic Electron Precipitation, and I or magnetic fields and particles associated with the solar winds, Coronal Mass Ejections and solar flares. Additionally, terrestrial influences could be incorporated such as earth magnetopause coupling and uncoupling, and changes to magnetic and electrical field lines. CM HD modelling parameters might include: coupling between fluid flow, current flow, and magnetic fields; PDEs which can be solved by Finite Element Method (FEM), internal pressure, density of fluid (electrons), turbulence model if turbulent, Navier-Stokes if laminar, components of the current flow and magnetic field, boundary conditions use different electron gradients as boundaries. CEHD modelling parameters might include: fluid motion, shape deformation, electric field gradient, EHD flow patterns, interfacial forces, size and shape of ion clouds and density, ionic composition, electric force and associated magnetic force when the charged particles move. The Convergence stage would involve predicting sensory values (most likely, macroscopic ones) at certain times and locations within the digital twin and comparing them to the actual data detected in the physical twin, exactly as the first to third aspects of the invention call for, appropriately adjusted as described. The convergence input would be the output of the FTRT model, which would show the predicted evolution of (purely by way of example): the density, gradient, internal properties and bulk-movement of IGDs in relation to their ability to impact radio communications or radar. Analysis of said impact would come from comparing the predicted values to actual historical data which would then provide insight as to likely impacts in predictive models. This would then be communicated to persons of interest. This internal structure and bulk movement is very similar to the advection I convection concepts described in the fifth aspect. Citations: (1) Jahn et al: “Towards real-time fire data synthesis using numerical simulations”: published 19 January 2021, Journal of Fire Sciences 2021, Vol. 39(3) 224-239, https: / / doi.Org / 10.1177 / 0734904121993449. (2) Zhang et al (Hong Kong Polytechnic University): “Building Artificial Intelligence Digital Fire (AID-Fire) system: a real-scale demonstration”, published online 13th October 2022 by Elsevier Ltd, Journal of Building Engineering #62, https: / / doi.Org / 10.1016 / i.jobe.2022.105363. (3) Buffington et al (University of Texas): “Brain-STORM: a deep learning model for computationally fast transient high-rise fire simulations", published online 7th September 2021 by Elsevier Ltd, Fire Safety Journal #125; https: / / doi.Org / 10.1016 / i.firesaf.2O21.103443. (4) Zhu et al (Southeast University Nanjing, University of Surrey, Guangzhou University): “Fast prediction for multi-parameters (concentration, temperature and humidity) of indoor environment towards the online control of HVAC system", published online in Building Simulation, volume 14, No. 3 in 2021: https: / / doi.org / 10.1007 / s12273-020-07Q9-z (5) Ishii et al: “Space weather impact on radio communication and navigation", published online by Elsevier Ltd, Science Direct (www.sciencedirect.com), January 2024 © COSPAR; Space weather impact on radio communication and navigation - ScienceDirect

Claims

1. A computer-implemented method for improving the energy efficiency of a Heating, Ventilation or Air Conditioning (“HVAC”) system within a built structure and simultaneously improving fire-safety within the structure by means of creating Faster Than Real Time (“FTRT”) predictive computational models of both Indoor Air Quality (“IAQ”) and fire within a digital twin of the structure, the structure being the physical twin, the method comprising;a computer processor configured to create one or more baseline computational IAQ models within the digital twin (hereinafter, a “baseline IAQ model”), and one or more baseline fire models (hereinafter, a “baseline fire model”) in or on the digital twin, wherein a baseline IAQ or fire model is a computational model specified in such a way that it cannot be run in FTRT, and wherein the processor also creates one or more FTRT computational IAQ models (hereinafter, an “FTRT IAQ model”) within the digital twin, and one or more FTRT fire models (hereinafter, an “FTRT fire model”) in or on the digital twin; andwherein the outputs of both the baseline and FTRT IAQ and fire models include one or more simulated characteristics of the IAQ (hereinafter, “simulated IAQ data”), and one or more simulated characteristics of a fire (hereinafter, “simulated fire data”) relating to one or more locations within the digital twin, at one or more time-steps in the one or more simulations; andwherein the processor compares the corresponding simulated IAQ and fire data of both types of model and, by applying machine learning, is trained to construct predictive FTRT IAQ and fire models, the processor further configured with a communications device to send or receive data to or from the physical twin.

2. The method of claim 1, wherein the processor is configured to receive ongoing communications of real sensory data relating to one or more physical characteristics of the IAQ (hereinafter, “real IAQ data”) and a fire (hereinafter, “the real fire data”) within or on the physical twin, the processor further configured to apply machine learning to the received real IAQ or fire data, as the case may be, and adjust the weights or biases of the FTRT IAQ and fire models so that, in realtime, one or more outputs of the FTRT IAQ and fire models tend towards the values of the received real IAQ or fire data.

3. The method of claim 1 or claim 2, wherein the simulated or real IAQ and fire data comprises data relating to ambient levels, or rates of change of ambient levels, of the following:temperature;carbon dioxide;humidity;smoke;at one or more simulated or real locations within the digital or physical twin, and wherein the real sensors within the physical twin are configured within the same housing to simultaneously communicate, to the processor, data which relates to both IAQ and the presence, or risk, of fire at one or more real locations.

4. The method of any of the preceding claims, wherein the algorithms, tools or techniques of machine learning include any relating to:a neural network;a support vector machine;a random forest technique;a k-nearest neighbour technique;a symbolic regression technique;or equivalent.

5. The method of any of the preceding claims, wherein the processor employs a train, validate and test process, or equivalent, to any of:the one or more baseline IAQ or fire models;the one or more FTRT IAQ or fire models;the real or simulated IAQ or fire data.

6. The method of any of the preceding claims, wherein a physical twin is a built structure including any of:a high-rise or multi-occupancy building;any other residential, commercial, or government building;a building on a military base;a compartment within any of the foregoing buildings;an oil or gas rig, or storage facility for oil or gas;a crewed or uncrewed vessel, including a maritime vessel;a road or rail tunnel, including a station within a tunnel.

7. The method of any of the preceding claims, wherein the simulated or real IAQ data relating to the digital or physical twin further comprises data relating to ambient levels, or rates of change of ambient levels, of any of:oxygen (“O2”);airflow;carbon monoxide (“CO”);volatile organic compounds (“VOCs”);aerosols, comprising any of;viruses;bacteria;mould;fungi;harmful pollen;toxic gases;nerve-agents;relating to, or transported in, the air at one or more simulated or real locations within the digital or physical twin.

8. The method of claim 7, wherein the processor is configured to model the diffusion of any of the aerosols suspended in the air, as well as the bulk transport of the aerosols within the modelled air.

9. The method of any of the preceding claims, wherein the simulated or real fire data relating to the digital or physical twin further comprises data relating to ambient levels, or rates of change of ambient levels, of any of:oxygen;flame;airflow;carbon monoxide;hydrogen cyanide;hydrogen chloride;sulphur dioxide;nitrogen dioxide;at one or more simulated or real locations within or on the digital or physical twin.

10. The method of any of the preceding claims, wherein the processor is configured to communicate any of:an instruction to a remote device or system to perform an action; an alert to a user to perform an action;in response to one or more outputs of any of the FTRTIAQ or fire models.

11. The method of any of the preceding claims, wherein the data relating to any of the outputs of the one or more baseline or FTRT IAQ or fire models is in the form of a 2-dimensional or 3-dimensional representation of the digital twin.

12. A computer readable medium comprising executable instructions that when executed by a computer cause the computer to perform the method of any of the preceding claims.

13. A system for improving the energy efficiency of an HVAC system and simultaneously improving fire-safety within a built structure (“physical twin”), adapted to perform the method of any of claims 1 to 11.

14. The system of claim 13, wherein the system is configured to send information to, or receive information from, a remote device or system and wherein said information may include one or more instructions to perform an action.

15. The system of claim 14, wherein the system is communicatively or operatively linked to any of:an HVAC system for the physical twin;a fire-safety system for the physical twin;a building management system, or equivalent, that is communicatively or operatively linked to either or both of an HVAC or fire-safety system for the physical twin.