This algorithm is based on the weight (adjacency) matrix of a weighted network and helps to solve complex network MST problem easily, efficiently and effectively. In this study, we have developed a new GIS tool using most commonly known rudimentary algorithm called Prim's algorithm to construct the minimum spanning tree of a connected, undirected and weighted road network. I could share the modifications I made to get it to work, but it wouldn’t be a readily mergeable PR as it breaks a few things in epw.py.Minimum spanning tree (MST) of a connected, undirected and weighted network is a tree of that network consisting of all its nodes and the sum of weights of all its edges is minimum among all such possible spanning trees of the same network. From what I gathered, the case of an analysis period shorter than a full year is not supported. But again, perhaps this is insignificant. I guess the effect of the change has been deemed minimal and this is better than having an hour shift all along.Īnyway, this seems even more wrong if the year is incomplete, as the last value may match the next to last even less. This must have been discussed already, and I don’t mean to reopen the discussion. For instance, midnight air temperature on two successive new year’s eve may be very different so this move may send a -5☌ just after a -5☌, introducing a 10☌ step. I find it strange to do even on full years because it may introduce a step while the data may be meant to be more or less continuous. # if the first value is at 1AM, move first item to end position line.append(str(self._data._values))Īnother thing that seems wrong is the first value being pushed to the end position:.for field in xrange(0, self._num_of_fields):.for hour in xrange(0, len(annual_a_per.datetimes)):.annual_a_per = AnalysisPeriod(is_leap_year=self.is_leap_year).I managed to override to_file_string to reuse the analysis period created in from_missing_values rather than creating an annual analysis period here: ladybug-tools/ladybug/blob/e19cccfeb46f6b0ad3a50dae9399dc24fd29e54b/ladybug/epw.py#L1545-L1550 Then I got this length error exception while writing the EPW file. Timestep=timestep, is_leap_year=is_leap_year # Initialize the class with all data missing I’ve been overriding EPW.from_missing_values to allow it to create shorter periods (still with full days): from_missing_values( So this should get you those starting EPWs in the format you want and it really is a matter of just stitching files together.Ĭan you please clarify whether Ladybug can export files shorter than a full year? FYI, you can still overwrite the years of the exported EPW by setting the values of the years data collection on the EPW object. Hopefully, the Ladybug Tools SDK already gets you 90% of the way towards making your own EPWs and writing the “stitching script” to run at the end is not that much of an extra effort. And, at the end of the simulation, you get results in chunks of a year, which are much easier to manage, analyze, and visualize.įor these few cases where you really need those first few days of the simulation to match reality within a few percent, I don’t think it’s that much to ask you to write your own script that stiches together the annual EPWs that you export from Ladybug. At least with that approach, you can run the EnergyPlus simulations in parallel, which could save a lot of time. In fact, if someone were running a multi-year simulation to inform design decisions, it’s probably more useful to generate a few EPWs (one for each year) and then run a few EnergyPlus simulations for each of the years. But, 99% of the simulations that people run with Ladybug Tools don’t need the results to perfectly match real-world measurements for the first week of January. I know that the EnergyPlus developers added it primary for validation/calibration purposes and I know this is what you are doing here. We can support leap years (that’s why you have both 20 hard-coded there) but Ladybug Tools data is always in units of a year or smaller.įrom another perspective, the ability to simulate a multi-year EPW is also not all that useful to design decisions. But it’s just not worth the sacrifice of analysis capabilities we would have to make in Ladybug Tools to support something like this. It doesn’t have to worry as much about the aftermath of how you analyze, visualize, manage, and usefully interpret the simulation results. EnergyPlus can do it because it’s an engine and it’s primarily concerned with running simulations. The value that Ladybug Tools gains by dealing with timeseries data in units of a year (or smaller) is just too great for us to change the Ladybug Tools data structures. Yes, it’s possible with E+ but it’s intentionally not possible with Ladybug Tools.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |