Template talk:Infobox power station/Archive 2

Archive 1

Archive 2

Archive 3

Unknown parameters

Now that these are cleaned up, people can start working on Category:Pages using infobox power station with unknown parameters. the entries are sorted by the name of the unknown parameter. for example, Cottam power stations is currently sorted under B due to the use of |boiler_manu_other= which is not a supported parameter. Frietjes (talk) 22:49, 24 February 2015 (UTC)

Frietjes I fixed more than 800 pages. 325 pages left. -- Magioladitis (talk) 18:13, 25 February 2015 (UTC)

Magioladitis, mostly correct, but we need to be careful here since this is not a wind farm. Frietjes (talk) 18:27, 25 February 2015 (UTC)

Magioladitis, and this will expose some deleted templates, again not a wind farm. Frietjes (talk) 18:29, 25 February 2015 (UTC)

Frietjes please fix them on site. There were at about 10 pages with |elevation=. -- Magioladitis (talk) 18:36, 25 February 2015 (UTC)

Magioladitis, okay, will change them to |altitude=, which is also unsupported, but will allow us to discuss if this is an important field to have for hydroplants. I would say the absolute altitude is not as important as the head, but still could be of interest. Frietjes (talk) 18:40, 25 February 2015 (UTC)

@Beagel, Frietjes, and Rehman: 245 pages left. Mainly with |technology=. -- Magioladitis (talk) 22:59, 25 February 2015 (UTC)

@Beagel and Rehman: what should be done with |technology=, |secondary_fuel_capacity=, |reactor_types=? -- Magioladitis (talk) 08:17, 27 February 2015 (UTC)

@Beagel, Frietjes, and Rehman: 233 pages left. Parameters: |licence_expires=, |local_name= found. -- Magioladitis (talk) 08:36, 27 February 2015 (UTC)

@Magioladitis: Is there a way we could get a table showing which article is using what unknown param (like Plastikspork did)? That would make it easier to spot what line needs editing... Rehman 13:31, 27 February 2015 (UTC)

@Rehman: all pages under T in Category:Pages using infobox power station with unknown parameters use |technology=. Pages are sorted by unknown parameter's first letter. -- Magioladitis (talk) 13:37, 27 February 2015 (UTC)

Ahhh, okay got it. I knew that... :P Rehman 13:43, 27 February 2015 (UTC)

|reactor_types= should be changed to |np_reactor_type=. |technology= should be checked manually, unfortunately. Although I think in most of cases it could be just deleted, in some cases it is used to indicated combined cycle, for which we have a separate field. |secondary_fuel_capacity= and |licence_expires= could be just deleted. For |local_name= (Ottovale coke works), I just added it after the name in parentheses. There is an issue with |reactors_cancelled_mw=. I think that information about cancelled units (not only for NPPs) is important, so it should be changed to |ps_units_cancelled= to be in line with other similar fields (operational, uc, planned, decommissioned). I propose to add this field. For |location_type= we probably need |wave_location_type=. Beagel (talk) 17:54, 28 February 2015 (UTC)

I added |ps_units_cancelled= to the template. It seems that in meantime all |reactors_cancelled_mw= were removed. Beagel (talk) 09:41, 14 March 2015 (UTC)

@Frietjes, Magioladitis, and Rehman:. Is it possible to remove |max_planned_cap= by bot in these cases there is no value provided? It would dramatically decrease the workload. If value is given for this para, it should be solved manually. I would like to ask also not to mark |relief= as unknown parameter and not to remove it. This is a standard parameter for location maps. Right now this infobox here uses automatically relief location map. However, in some cases the map without relief works better and adding empty |relief= allows to use it. At the same time, I don't think we should include this in the skeleton template to avoid confusion. Beagel (talk) 08:18, 1 March 2015 (UTC)

I removed empty |max_planned_cap=. -- Magioladitis (talk) 10:33, 1 March 2015 (UTC)

Thank you very much. I think that if there is any other unsupported empty para, it could be also removed automatically. Beagel (talk) 10:43, 1 March 2015 (UTC)

Does anybody knows which para populates Category:Pages using infobox power station with unknown parameters under C? In some cases I can't find something wrong. Beagel (talk) 10:43, 1 March 2015 (UTC)

Hopefully this table will help, once someone creates it. Rehman 10:47, 1 March 2015 (UTC)

Beagel If you see my changes is |coordinates_ref=. Rehman forgot to add it and will take us some time to get the category updated. Moreover, the latest changes in the infobox force alternative parameter names to be included in the tracking category. -- Magioladitis (talk) 10:52, 1 March 2015 (UTC)

Ok, I see. Thank you. Beagel (talk) 10:57, 1 March 2015 (UTC)

I did some null edits and now we are back to 839. -- Magioladitis (talk) 12:52, 1 March 2015 (UTC)

Down to 810. How do we proceed? -- Magioladitis (talk) 20:49, 1 March 2015 (UTC)

Beagel please add |relief= to the documentation. -- Magioladitis (talk) 22:10, 4 March 2015 (UTC)

I added it. -- Magioladitis (talk) 19:18, 12 March 2015 (UTC)

Magioladitis. I don't think it is a good idea to add this parameter to the skeleton template, so it would be automatically copied to the every new infobox. If this parameter is not added, the infobox uses a relief map. If the parameter is added but no value added, it uses a flat map. In most of cases people will not add the value to this field, so it will result with de facto change back to the flat maps. I personally prefer the relief maps. The reason I added this para to some infoboxes is, that for some maps the flat map is more user-friendly (taking account colour blinded people) than the relief map (e.g. in the case of Uganda). But I think that using the flat map should be exception, not a rule. Therefore I agree if this para is listed in the documentation (explaining how to use parameters) but not in the skeleton template. Beagel (talk) 07:21, 14 March 2015 (UTC)

Beagel I rmeoved it from skeleton template just now. -- Magioladitis (talk) 07:23, 14 March 2015 (UTC)

Down to 745. But I think Frietjes's approach was more realistic. @Beagel and Rehman: You'll have to deal with parameters such as |licence_expires=, |local_name= and |technology=. -- Magioladitis (talk) 23:25, 12 March 2015 (UTC)

For |licence_expires= I would say just delete it. Beagel (talk) 07:24, 14 March 2015 (UTC)

Done. -- Magioladitis (talk) 07:34, 14 March 2015 (UTC)

Beagel there are two pages with |coordinates_format=. The value is dms. -- Magioladitis (talk) 07:40, 14 March 2015 (UTC)

Probably it has something to do with {{coordinates}}. I think we better keep these, although I am not sure if this really necessary. But again, if kept, I don't think we should add this to the skeleton template. Beagel (talk) 07:50, 14 March 2015 (UTC)

@Beagel, Frietjes, and Rehman: Down to 144. -- Magioladitis (talk) 13:49, 14 March 2015 (UTC)

After delisting |embed= we are down 133. -- Magioladitis (talk) 23:31, 14 March 2015 (UTC)

New section for thermal power station

Resolved

 – Duplicate of "Thermal Power Station section added with technology and feeding mine" section above. Rehman 01:58, 21 March 2015 (UTC)

Way back when nuclear, hydro, wind, and all the other smaller templates were merged into this infobox, little preference was given on adding more specific fields to the more common types of power stations, like thermal power stations (which runs on coal, oil, etc). Since then, a number of parameters specific to only thermal power stations has been added to the footer section, causing much confusion to someone who hasn't been following the developments of the template. To make things more straight forward, I propose the following as one change:

• Add a new section for thermal power stations, so the bottom section would only have parameters that could be used simultaneously with any other section.
• Instance where two sections would need a similar field (i.e nuclear and thermal needing cooling source), add two separate fields to both sections.

This would simplify things a lot. And if there is proposal for change, it could be happily confined to the relevant section only, and not the general footer. The footer may only contain the most common general info, applicable to any type of power stations. Rehman 13:53, 17 March 2015 (UTC)

Ping Beagel, NortyNort, Frietjes, Robertiki. I hope to do so this weekend. Do post here if you have any suggestions or comments. At the moment, I have a single new section in mind (for coal, oil, etc) as I mentioned above. But I would like your views on expanding that to the most common thermal types; maybe separate sections for coal, oil, and others? Rehman 15:23, 18 March 2015 (UTC)

@Rehman:: Robertiki already created this section called Thermal power station. There is also a discussion to move additional parameters to this newly created section. But I don't think that we should duplicate fields in the different sections. This would just to overload the template's code. Saying this, I think that cooling type as also thermal capacity should stay in the end section. Beagel (talk) 17:55, 18 March 2015 (UTC)

That's great :) Sorry, I wasn't following closely on the edits to the template lately. It would not overload the code, as all the sections are |child=yes sections. With this in mind, we could actually increase the quality of the infobox contents in general, rather than have a giant header and footer, and a tiny portion in the middle relating to the power station specifics. Not saying we should bloat up all section, but instead we should add what's necessary and appropriate instead of being limited by the technicalities of the template. We raised the template overload topic long time ago when the whole template was in a single skeleton. Rehman 22:47, 18 March 2015 (UTC)

Status

@Rehman: I think that using C for 'cancelled' may create confusion as a lot of people do not read the documentation and there is a risk that C would be used in the meaning of 'commissioned'. Beagel (talk) 17:44, 21 March 2015 (UTC)

IMO, if someone did not read the documentation (and realize that the field autofills), they would most probably just type in the whole thing in various formats like "Cancelled", "Cancelled project", "Project cancelled", etc etc, which would all just skip autofill without harm... Rehman 05:13, 22 March 2015 (UTC)

ps_units_operational

Resolved

 – Beagel (talk) 08:55, 22 March 2015 (UTC)

@Magioladitis: Why Yobot is removing |ps_units_operational= if empty? Beagel (talk) 11:18, 1 March 2015 (UTC)

Beagel My mistake. I fixed. I am getting confused with all these parameters. -- Magioladitis (talk) 11:20, 1 March 2015 (UTC)

Nameplate capacity

Previous versions added automatically unit MW to capacity fields if the value was provided without a unit. It does not anymore which leaves a number of 'nameplate capacity' fields without any units. I propose to restore this function for 'ps_electrical_capacity' and 'ps_thermal_capacity' fields. The unit MW should be probably also linked to Watt#Megawatt. Beagel (talk) 16:59, 24 February 2015 (UTC)

There was no recent changes that affected this. Nevertheless, I believe this creates more difficulty than simplifying things, for most users. Someone who is not much of a Infobox power station expert (like everyone in this talkpage), would like to just copy the skeleton, and then fill in, in probably GW or even KW, and have their own preferred linking. But enabling that automation would just create stress on having to come back and understand the various formats needed to make it work. Initially, I was against all automation in the template, but realized that automating a more complex thing would actually be helpful (like the nuclear portion). Just my opinion. Regards, Rehman 13:42, 27 February 2015 (UTC)

I don't know how recent it is. It worked this way that MW or GWH was automatically added if no units (letters) were used, otherwise it was overruled by manually added text. At the moment there is a number of infoboxes where capacity and generation amount is given without units. Beagel (talk) 17:57, 28 February 2015 (UTC)

Ehm ... it happened here [1] and I understand why. I have now restored the generation unit GW·h automatic addition, to inspire the editors about that particular unit official scripting, with a mid-air dot. For the capacity units I would suggest to wait after the present major changing sweep has settled. --Robertiki (talk) 14:34, 13 March 2015 (UTC)

@Robertiki and Rehman: Removing |max_planned_cap= has created problem with projects still under construction or in the planning phase. If we insist that |ps_electrical_capacity= should apply only for current gross installed capacity, it excludes any capacity information from the infobox for these plants as also for decommissioned plants. This is not right. I think we should allow more broader interpretation of this para. Beagel (talk) 09:29, 21 March 2015 (UTC)

Agree. I think that |ps_electrical_capacity= should also be used for the planned value by adding the description (planned). In this way, when the power plant is commissioned, the editors who look after the updating have simply to delete the description. With |max_planned_cap=, instead, it was necessary to move the first value to the new parameter, which if not present, it means go and find it and copy it. We can also use it with the description (canceled) or (decommissioned) when appropriate. The advantage is that we have a infobox that shows a more constant format. Alternate solution to the (description) is adding a new field to follow immediately |ps_electrical_capacity=, i.e. for example ps_power_status with a selection of: planned, operating, cancelled, decommissioned, mothballed, etc. In case of upgrades or other variations, we could suggest indicating the relevant values, 'br/' separated, for example (planned upgrade) ? --Robertiki (talk) 14:00, 22 March 2015 (UTC)

With my last update to the documentation, I had assumed that this was solved. ps_electrical_capacity may contain current or future value, depending on the article. A fully operational power station may have current capacity listed, whereas a power station in proposal stage may list planned capacity only. Of course for those with current and a planned value, adding the current value is the obvious way to go, because such information (planned capacity) for an existing operational plant does not belong in an infobox in the first place. I have updated the documentation to reflect this. Rehman 14:37, 22 March 2015 (UTC)

Agree that for an existing operational plant the planned capacity does not belong in an infobox, but planned upgrades could be freely inserted, separating the fields with 'br/' if the editor feels to do so.--Robertiki (talk) 14:48, 22 March 2015 (UTC)

Reactor supplier

The documentation needs some clarification how to use |np_reactor_supplier= together with |ps_units_manu_model=. It seems not to clear. E.g. where we should put the reactor model? Beagel (talk) 08:42, 1 March 2015 (UTC)

@Frietjes, Magioladitis, NortyNort, Rehman, and Robertiki: I would like to repeat my question what to do with this? It seems to me that the best thing would be to remove |ps_units_manu_model= from the template and to restore a separate manufacturer and generator type fields for each type of power station. Beagel (talk) 08:54, 22 March 2015 (UTC)

Field is relevant only to power plants with a thermal section (cycle). Suggest to move the parameter in the new thermal section. --Robertiki (talk) 14:05, 22 March 2015 (UTC)

The field in question is relevant to all types of power stations. Rehman 14:45, 22 March 2015 (UTC)

You are right, I forgot, for example, the wind turbines.--Robertiki (talk) 14:52, 22 March 2015 (UTC)

Beagel: I am leaning toward leaving ps_units_manu_model as it is, but creating a new np_reactor_manu_model instead. As the earlier is about the equipment used to generate power, while the latter is not. Rehman 14:45, 22 March 2015 (UTC)

I am would propose creating a new th_heat_unit_manu_model. The heat source unit could be a nuclear reactor, could be a fossil boiler, could be a solar boiler, ... --Robertiki (talk) 15:02, 22 March 2015 (UTC)

|ps_units_manu_model= shows at the bottom as "Make and model" which is rather generic. Could we rename the field |units_manu_model= to cover all turbine/generator combos? I have never updated such a field but it may be useful.--NortyNort (Holla) 00:47, 23 March 2015 (UTC)

Parameter scan

As requested, here is a recent scan of parameter usage

Parameter usage
Count	Field	In template?
1	tide_barrage_length	Y
1	tide_channel_speed	Y
1	ps_units_cancelled	Y
1	tide_channel_width	Y
1	tide_crosses	Y
1	location_map_alt	Y
2	wave_site_area	Y
2	tide_technology	Y
2	solar_cpv_concentration	Y
2	np_fuel_type	Y
3	wave_shore_distance	Y
5	wave_technology	Y
6	psps_pumps	Y
7	geo_temp_requirement	Y
7	coordinates	N
8	geo_well_depth	Y
9	solar_csp_heliostats	Y
9	th_feed_mine	Y
10	geo_well_count	Y
10	embed	Y
10	psps_penstocks	Y
12	geo_type	Y
14	wind_site_usage	Y
18	coordinates_ref	Y
19	image_alt	Y
19	wind_rated_speed	Y
22	max_planned_cap	N
23	wind_offshore_depth	Y
25	wind_site_elevation	Y
26	psps_generators	Y
32	solar_csp_technology	Y
32	location_map_size	Y
44	wind_offshore_distance	Y
44	relief	Y
46	thermal_capacity	Y
48	wind_site_area	Y
49	ps_units_uc	Y
50	psps_pumpgenerators	Y
52	th_cogeneration	Y
53	psps_hydraulic_head	Y
53	th_fuel_tertiary	Y
54	psps_lower_res_capacity	Y
61	ps_electrical_cap_fac	Y
62	psps_upper_res_capacity	Y
63	ps_units_decommissioned	Y
63	psps_lower_res	Y
70	psps_upper_res	Y
72	ps_units_planned	Y
74	wind_hub_height	Y
74	wind_rotor_diameter	Y
89	th_combined_cycle	Y
92	image_size	Y
103	th_fuel_secondary	Y
106	th_cooling_source	Y
107	solar_site_area	Y
148	wind_farm_type	Y
150	th_technology	Y
158	np_reactor_supplier	Y
169	extra	Y
190	solar_type	Y
207	np_reactor_type	Y
211	decommissioned	Y
235	location_map_caption	Y
243	name_official	Y
296	cost	Y
328	website	Y
367	ps_units_manu_model	Y
446	ps_annual_generation	Y
527	construction_began	Y
609	operator	Y
639	image_caption	Y
880	image	Y
1066	th_fuel_primary	Y
1156	ps_units_operational	Y
1205	lat_s	Y
1206	long_s	Y
1266	owner	Y
1344	lat_m	Y
1346	long_m	Y
1419	lat_NS	Y
1420	long_EW	Y
1550	location_map	Y
1560	commissioned	Y
1574	status	Y
1601	coordinates_display	Y
1607	coordinates_type	Y
1658	ps_electrical_capacity	Y
1665	lat_d	Y
1669	long_d	Y
1676	country	Y
1837	location	Y
1972	name	Y

Plastikspork _―Œ^(talk) 06:10, 22 March 2015 (UTC)

Triple thumbs up man. Thanks! Welcome back! Rehman 06:12, 22 March 2015 (UTC)

@Plastikspork:, would you be able to list the article uses one last time, for the following please:

• coordinates
• ps_thermal_capacity
• ps_storage_hours

And change the following parameters uses, so we can close this case for good:

• ps_cogeneration to th_cogeneration
• ps_combined_cycle to th_combined_cycle
• ps_cooling_source to th_cooling_source
• ps_fuel_primary to th_fuel_primary
• ps_fuel_secondary to th_fuel_secondary
• ps_fuel_tertiary to th_fuel_tertiary

Your assistance in this is very much appreciated. Once this is done, if you could run another final scan and update the tables on top, we could know if everything is in place, and finally close this multi-year maintenance project. (Note: the list of supported and unsupported parameters are slightly changed. The updated list can be found on the documentation page). Best regards, Rehman 07:34, 22 March 2015 (UTC)

Updated Plastikspork _―Œ^(talk) 23:14, 22 March 2015 (UTC)

@Plastikspork: Can you update the tables once more please? -- Magioladitis (talk) 18:56, 28 March 2015 (UTC)

Updated. Plastikspork _―Œ^(talk) 23:21, 28 March 2015 (UTC)

Thermal Power Station section added with technology and feeding mine

Down to 673 power station with unknown parameters. Realizing that technology and mine_type are heavily used parameters I have introduced a Thermal Power Station section for this two parameters. The result can be seen here: Bull Run Fossil Plant. If there is consensus about these additions, I will add the necessary documentation. --Robertiki (talk) 21:51, 13 March 2015 (UTC)

These parameters were used for some predecessor templates but were excluded later. Not really sure if they are needed here but I have no strong objections. Beagel (talk) 07:10, 14 March 2015 (UTC)

Beagel If we solve the |max_planned_cap= issue we are half way through. -- Magioladitis (talk) 07:19, 14 March 2015 (UTC)

Magioladitis, in the case the |ps_electrical_capacity= is empty or missing, I think we could change the |max_planned_cap= into |ps_electrical_capacity=. Beagel (talk) 10:01, 14 March 2015 (UTC)

Done. -- Magioladitis (talk) 16:21, 14 March 2015 (UTC)

I find that the technology parameter allows a fast search of specific thermal plants, without having to read through the text. And the information is alread there, I guess there are readers that rely on them. We have steam and gas turbines, reciprocating engines and stirling. Steam turbines could be Rankine or Allam cycle, conventional, critical or supercritical. Water, CO2 or mercury based fluid. I have to make some reasearch and order it in a table.--Robertiki (talk) 15:11, 14 March 2015 (UTC)

@Robertiki, Rehman, Magioladitis, and Frietjes: Should we move the following parameters into this newly created section as they are (mainly) thermal stations specific and mainly not usable for other type of stations:

• |ps_fuel_primary=
• |ps_fuel_secondary=
• |ps_fuel_tertiary=
• |ps_cogeneration=
• |ps_combined_cycle=

Beagel (talk) 15:52, 15 March 2015 (UTC)

Solar thermal station may use some or all of them. Example: Termosolar Borges --Robertiki (talk) 03:24, 16 March 2015 (UTC)

Termosolar Borges is a hybrid plant and as such there may be both sections to be represented in the infobox. Beagel (talk) 06:22, 16 March 2015 (UTC)

Same thought. Alright, let's move them. --Robertiki (talk) 00:48, 17 March 2015 (UTC)

I strongly support this section. And as Robertiki explained, we could also add a number of more specific fields relating to thermal power stations, reducing our maintenance backlog, and more importantly increasing the quality of thermal power station infoboxes.

Also, each section of the Infobox Power Station template uses a separate |child=yes template, so there is no issue of the template overloading, which was the case when the template was merged and created initially. With this in mind, I suggest we only remain commons fields in the footer section (fields which can be used in entirety along with any other section), and move the rest to the applicable sections. For example, |ps_cooling_source cannot be used along with wind farms (and hence is not a common footer parameter), and hence should be completely moved to Nuclear section. For those parameters which is applicable to two or more sections, duplicate it: |np_cooling_source and |th_cooling_source. That would make handling the whole template so much easier, and copying and using the template skeletion a breeze to someone not that familiar with using a complex infobox like this.

As I mentioned in the section below, I plan on doing the above during this weekend (today). I will update the skeleton, but not update the documentation yet. So we can discuss the outcome and take this step-by-step. Rehman 02:14, 21 March 2015 (UTC)

This is the change I propose (ignore the tracking category loss), and this is how it would look like. I will do the change later today, or tomorrow, if no one objects. Rehman 06:00, 21 March 2015 (UTC)

Just two things by fast reading. First, it would be enough to have combined cycle only for thermal power plants as combined cycle plants are mainly gas-fuelled. Second, I still think that electrical capacity and thermal capacity is better to keep together. I ams also little bit confused: if the size of the code is not matter anymore, why in this case we recently removed a number of valid fields (e.g. |constructor=, different reservoir capacities, separated fields for turbine manufacturer and model, |max_planned_cap= etc) from the template? Beagel (talk) 09:21, 21 March 2015 (UTC)

We could remove the CC field from the other sections any time if you really need, I just kept it for the sake of keeping. I somewhat agree with the thermal capacity field, but keeping it the way it is now does take a lot of headaches away. I think there's a way to keep separate thermal capacity fields for each section, but make it display next to the electrical capacity field, let me try working on that.^{Did the changes so that thermal and electrical capacity are together.} I'm a bit lost on the code size as well. Perhaps we did that when we did not have separate sebclassing sections within the code earlier? On a separate comment, I still think that the header/footer section is currently a bit long (lengthwise), but this is just my personal opinion. Technically, we do have more space using subclassing. Rehman 02:40, 22 March 2015 (UTC)

I removed combined cycle for geothermal and nuclear. Beagel (talk) 08:46, 22 March 2015 (UTC)

@Rehman: There is always the testcases to try things. Better not do any changes directly to the main code. -- Magioladitis (talk) 10:05, 21 March 2015 (UTC)

All the proposed stuff I posted in the above links are in sandboxes... Right? Rehman 02:24, 22 March 2015 (UTC)

Proposing to change section name to Thermal Power Section instead of Thermal Power Station. Example: Alvarado I would make more sense. --Robertiki (talk) 04:49, 29 March 2015 (UTC)

Nonsense parameters

Is it possible to create a list about articles using |th_fuel_primary= or |th_technology= with a value 'Hydroelectric', 'Hydroelectricity' or something similar? As in most of cases these articles need {{Infobox dam}} instead of {{Infobox power station}}, it would be better to list them for changing manually instead of automatic removal of these paras. Beagel (talk) 18:38, 22 March 2015 (UTC)

Same applies if a value of these parameters is 'Geothermal', 'Wind', 'Solar', or 'Wave'. Beagel (talk) 19:10, 22 March 2015 (UTC)

@Magioladitis and Plastikspork: Could we create this list? Beagel (talk) 23:56, 27 March 2015 (UTC)

@Beagel: Here you go:

Fuels
Count	type
1	41kg of 2% enriched uranium
1	46411kg of natural uranium metal (UO2 and U33O8)
1	Advanced biomass
1	Arabian Heavy Crude Oil
1	Arabian Super Light
1	Biomass/Natural Gas (prospective)
1	biomass (straw and wood pellets) (unit 2)
1	Biomass ((wood pellets)), ((sugarcane)), and ((straw)),
1	Bituminous coal,
1	Bituminous coal
1	Bituminous Coal
1	Bituminous coal, distillate fuel oil
1	Bituminous coal, natural gas, distillate fuel oil
1	Bituminous coal, natural gas, fuel oil
1	Bituminous coal, Coal synfuel,
1	brown coal
1	Bunker C (#6 Heavy Oil)
1	city gas
1	coal,
1	Coal (1820-1994)
1	Coal (1853-1985)
1	Coal (3.7%)
1	Coal (4 power units)
1	Coal (Bituminous)
1	Coal (Bituminous), Natural Gas, Natural Gas
1	coal / diesel oil
1	coal-fired
1	Coal from North Karanpura and Central Coal field Ltd and Light Diesel Oil
1	Coal, gas
1	Coal (lignite)
1	Coal, Natural Gas
1	Coal, Oil, gas
1	Coal, oil, natural gas
1	Coal (Open-cut mine)
1	Coal Imported from Iran
1	subbituminous coa
1	Coal Synfuel
1	Thermal coal
1	Coal(unit 1)
1	coal (Units 1 & 2)
1	Coal (units 1–4)
1	Coke
1	cooling by system of artificial ponds
1	Crude oil
1	Crude Oil
1	Fuel oil
1	Diesel
1	distillate fuel oil for peaking units
1	Fossil Fuel: Coal
1	fuel oil
1	Fuel oil (6.8%)
1	Fuel oil (backup fuel)
1	Fuel oil (converted from Coal)
1	Heavy oil
1	Fuel oil (Units 1–3)
1	Fuel oil (units 1 and 2)
1	Furnace Oil
1	FURNACE OIL/HSD
1	Gas-fired
1	geothermal power
1	Geothermal
1	Heavy Oil
1	heavy fuel oil / natural gas
1	Heavy Furnace Oil (HFO), Light Diesel Oil (LDO)
1	Heavy oil
1	high-grade, solid black coal
1	High Speed Diesel
1	Hydroelectric and steam
1	Hydroelectric
1	Hydro
1	Landfill gas
1	Light crude oil
1	Lignite-Based
1	Lignite Coal
1	lignite, natural gas
1	lignite (open pit mine)
1	LNG
1	LPG
1	Liquid natural gas
1	LNG
1	low-sulphur bituminous coal from West Virginia, natural gas
1	Low-sulphur coal
1	Miscanthus
1	Municipal solid waste (unit 3)
1	natural gas,
1	Natural Gas
1	natural gas (1985-present)
1	natural gas (1994-present)
1	Natural gas (78%)
1	Natural Gas/Bituminous Coal
1	natural gas (combined heating power plant)
1	Natural gas/diesel fuel/kerosene
1	Natural gas-fired (originally Oil-fired)
1	natural gas/fuel oil
1	Natural gas, Fuel Oil
1	natural gas, fuel oil, coal
1	Natural gas, Liquefied natural gas
1	Natural gas, originally coal
1	natural gass
1	Natural gas (since 2013)
1	natural gas, subbituminous coal
1	Natural gas (units 1 and 2)
1	Natural gas (Units 4 and 5)
1	Non-hazardous and commercial waste
1	Oil and Gas
1	Oil and natural gas (Unit 3 & 4)
1	Oil (A station only)
1	Oil Fired (HFO & Diesel)
1	Oil seed rape
1	Oil shale gas
1	Oil shale (until 2011)
1	Peat (11.5%)
1	Petcoke
1	Petroleum coke
1	petroleum coke, distillate fuel oil, residual fuel oil, bituminous coal, natural gas
1	poultry litter
1	Powder River Basin Coal
1	Powder River Basin sub-bituminous coal
1	Pulverized coal
1	Refuse derived fuel, Wood fuel
1	Residual fuel oil, bituminous coal, natural gas
1	Residual Fuel Oil (RFO)
1	Solar power & Diesel fuel
1	Solar thermal
1	Straw
1	Sub-bituminous coal
1	Subbituminous coal, kerosene
1	sub-bituminous coal, oil
1	Subbituminous and Bituminous coal, natural gas
1	Sub-bituminous pulverized coal
1	subbituminous coal, tires
1	Syngas
1	Tidal
1	Town gas
1	Usibelli Sub-bituminous coal
1	Various types of wood waste, including green wood residue from forestry and tree trimming operations, railroad ties, demolition waste and sawdust
1	Western Coal and formerly nuclear
1	Wind
1	Wood biomass (2014)
1	wood waste
2	Anthracite
2	biodiesel
2	Biogas
2	Biomass (straw)
2	bituminous coal, natural gas
2	crude oil
2	Diesel fuel
2	diesel oil
2	Distillate fuel oil
2	fuel oil
2	Fuel Oil
2	Fuel oil, Crude oil
2	Heavy fuel oil
2	Hydrogen
2	Hydropower
2	Light fuel oil
2	mazut
2	Natural Gas
2	Natural gas or fuel oil
2	Organic waste
2	Orimulsion
2	Shale oil
2	subbituminous coal,
2	Sub-bituminous coal
2	Tide
2	Waste heat
2	Water
2	Western Coal from Utah or Wyoming
2	Wood chips
3	Coal seam gas
3	Fuel Oil
3	Hard coal
3	hydro
3	mazut
3	Municipal waste
3	Naphtha
3	solar
3	Solar power
3	Water
4	Biofuel
4	Brown coal
4	Coal,
4	distillate fuel oil
5	Bagasse
5	coal-fired
5	Fuel oil
5	Gas
5	natural gas
5	Oil
6	heavy fuel oil
6	Oil shale
6	sub-bituminous coal
6	Subbituminous coal
7	biomass
7	Diesel fuel
7	Diesel
7	geothermal
8	Peat
9	natural gas and coal
9	oil
10	coal
10	coal
10	natural gas and coke
10	Natural gas-fired
10	Waste
11	Nuclear
11	Oil-fired
13	Natural gas-fired
15	Biomass
15	Biomass
15	Coal-fired
16	hydroelectric
22	Fuel oil
23	lignite
23	Natural gas
24	Hydroelectricity
25	Natural Gas
33	natural gas
57	Bituminous coal
71	Coal-fired
71	Hydropower
83	Coal
95	Natural gas
96	Wind
124	Coal

Enjoy :) Plastikspork _―Œ^(talk) 01:30, 28 March 2015 (UTC)

Thank you. It was less than I expected. But a lot of similar cases were cleaned-up during the parameters update. Beagel (talk) 12:45, 28 March 2015 (UTC)

@Plastikspork: Could you please check also the value 'Hydropower'? I just found Lubilia Hydroelectric Power Station which used this value and there may be more. Beagel (talk) 19:18, 28 March 2015 (UTC)

@Beagel: You were right, my search pattern was incomplete, I updated the tables above. Once those are cleaned up, ping me, and I will run the scan again. And I can scan for other nonsense values if you like. Thanks! Plastikspork _―Œ^(talk) 00:15, 29 March 2015 (UTC)

All listed wind farms nonsense parameter th_fuel_primary and th_combined_cycle removed. --Robertiki (talk) 04:37, 29 March 2015 (UTC)

Thank you. I think I will enjoy it for a long time. Beagel (talk) 13:26, 29 March 2015 (UTC)

@Rehman, Frietjes, and Magioladitis: How do we have to show coordinates and a location map in the cases of multiple coordinates like the Cerro Prieto Geothermal Power Station. Maybe we should re-include |coordinates= (but do not include in the skeleton template)? Or is there any better idea what to do? Beagel (talk) 13:25, 29 March 2015 (UTC)

Personally, for such rare cases, I just load up the facility on Google Maps, and pick an estimated average from the centre of the zone. Or better, use an official coordinates if mentioned on their website, etc. And for facilities like wind farms, I mention the coordinates as the first/lead turbine (if that info is available), or the centre turbine. IMO, for such rare cases, we should improvise on the article, rather than change on the infobox. Just my opinion though. Rehman 13:32, 29 March 2015 (UTC)

Beagel I was about to come here and leave a similar message. I think we should re-introduce |coordinates= and also find way to avoid adding empty |relief= in order to get the wanted result. -- Magioladitis (talk) 13:34, 29 March 2015 (UTC)

One thing you can do right now is use |lat_d= and |long_d= for the primary coordinates, and use |coordinates_ref=<br>{{coord|...}} for the "sub coordinates". Frietjes (talk) 13:40, 29 March 2015 (UTC)

for disabling the relief map, use |location_map_relief=no (just added yesno to make this work, default is still yes). Frietjes (talk) 13:51, 29 March 2015 (UTC)

|relief=no has the same impact. As the infobox use automatically the relief map, this para should be used only for disabling it. There is no practical use for |relief=yes. Beagel (talk) 14:19, 29 March 2015 (UTC)

This might not be not be that helpful but I usually add a separate map for multiple coords, that are far apart, in the appropriate section, ie Kishanganga Hydroelectric Plant. Infobox dam also has a separate field for HPPs but it doesn't show on the main map. I use Template:GeoGroupTemplate to allow readers to see all coordinates whether in the Infobox or in text, example Kolnbrein Dam.--NortyNort (Holla) 21:50, 29 March 2015 (UTC)

Solar Heliostats and linear parabolic mirrors to active surface and solar resource

I am talking about the old csp_units that have disapeared, while the heliostats number had survived. I thought it over, and instead of restoring the csp_units number or change the description of solar_csp_heliostats to 'number of heliostats or parabolic throughs', I propose to change it to solar_field_aperture (area). The number of mirrors is not of particular interest. Mirrors are not standard; either heliostats or parabolic troughs come in a variety of sizes, so knowing their number and size can be an interesting detail in the text, but the real significant value (and 'condensed' information) is the global capturing area, not to be confused with the site area. Another very important information, critical and typical of every solar site is the solar_resource (kWh/m2/year or kWh/ft2/year units).--Robertiki (talk) 23:54, 14 March 2015 (UTC)

Follow-up: I took a look at the whole Solar section and here are some thoughts, just in time before the number of articles about solar plants booms:

• section name: better naming could be "Solar field", because we may have just a solar field, and not a complete conversion process, like in a PV unit or a wind turbine
• solar_cpv_concentration applies also to CSP technology so name should be solar_concentration_ratio
• solar_csp_heliostats is specific only to one of the four CSP technologies. Dish Stirling have "dishes", Solar tower have "heliostats", Fresnel reflector have "long linear flat mirrors" and Parabolic trough have, guess, "troughs". Dish size, heliostat size, mirror size and trough size vary so knowing there number is not so characteristic. And anyway, what is interesting about Dish Stirling counting, finds place in the ps_units_xxxx parameters. The other three technologies have a steam turbines units count. Either solar_csp_heliostats should be dropped or changed to a generic solar_csp_collectors. I would prefer introduction of solar_field_aperture, so I suggest a compromise (in the future we could drop che collector count), adding both (and removing solar_csp_heliostats)
• solar_resource, as said, should be a must; energy production changes drammatically with same units, same nominal power, but different location and this information should really jump out in the infobox

--Robertiki (talk) 19:32, 6 April 2015 (UTC)

Thermal capacity

@Plastikspork: Why the bot is removing |ps_thermal_capacity=, e.g. here? Beagel (talk) 18:30, 22 March 2015 (UTC)

With current code geo_thermal_capacity, np_thermal_capacity, solar_thermal_capacity, th_thermal_capacity will overwrite each other. -- Magioladitis (talk) 00:21, 24 March 2015 (UTC)

Beagel To avoid this I suggest that we use a single |thermal_capacity=. -- Magioladitis (talk) 00:17, 28 March 2015 (UTC)

@Beagel: I merged everything to a single parameter |thermal_capacity=. This resolves the overwrite issue and it is as expected since the thermal capacity appears in the last section. -- Magioladitis (talk) 13:33, 28 March 2015 (UTC)

Only 45 pages have this parameter. I renamed everything. -- Magioladitis (talk) 14:02, 28 March 2015 (UTC)

Magioladitis. I oppose this move, as it effectively puts back the thermal section in the footer section, a section which can be used with any other section above. The field is not applicable to power plants like wind farms, etc. The move to separate the thermal capacities were only very recently done... Can it be undone so we can discuss first? The issue of overwriting can be suppressed by asking the bots to not touch the thermal fields, and instead list them for manual action... Rehman 11:33, 29 March 2015 (UTC)

Hi @Magioladitis:. Good day to you. I hope to change back the thermal section into individual parameters shortly... Please do comment asap if you object this. That is the only field in the footer section that does not apply to every section above. As for the usages, we could do a scan only on those sections and manually update the usages. This is the final potential parameter rename pending. Once this is sorted, and the fields usages at #Parameter scan and #Nonsense parameters are updated, we could finally close this stretched-out cleanup project. Rehman 03:07, 4 April 2015 (UTC)

My edit did not affect the placement of the parameter. All the parameters targeted the same place already. -- Magioladitis (talk) 14:44, 6 April 2015 (UTC)

There are not many uses of this parameter. Please, WP:FIXIT if you think the parameter should be split again. Please, be aware that if someone copies the blank infobox and puts the value in only one place the infobox won't show correctly in its previous form. The thermal capacity parameters should remain merged or completely split. There is no middle ground without potential problems. -- Magioladitis (talk) 20:04, 6 April 2015 (UTC)

Only a side note, the parameter is not much used because of incorrect factual information from the media. Example, see Archimede solar power plant and Kogan Creek Power Station which I have just corrected. My additions are here and here. Ridiculous, that sometimes the media mistakes, for example about the Archimede plant, the thermal power of 20 MW as an earlier electric power proposal reduced to the 5 MW invented by ENEL green pitches. And AREVA is no better. Understand that there are no 5 MW turbines-generators in the Archimede plant and no 44 MW turbines-generators in the Kogan Creek plant. All hybrid solar power boosting plants as described by most of media carry the same error. --Robertiki (talk) 23:41, 6 April 2015 (UTC)

Additional parameters to be updated

Magioladitis, could the bot do the following replacements of parameters:

• |technology= by |th_technology=
• |mine_type= by |th_feed_mine=
• |np_water_source= by |ps_cooling_source=
• |nuke_water_source= by |ps_cooling_source=

Thank you. Beagel (talk) 15:40, 15 March 2015 (UTC)

Beagel Done. -- Magioladitis (talk) 17:26, 15 March 2015 (UTC)

Down to 114 in Category:Pages using infobox power station with unknown parameters. -- Magioladitis (talk) 17:33, 15 March 2015 (UTC)

Beagel We have to deal with |pumped_storage=. Some articles have it with value "No". -- Magioladitis (talk) 08:16, 16 March 2015 (UTC)

I would say that we may delete this para. However, infoboxes having this para needs probably larger cleanup and in some cases replacing with {{Infobox dam}}, so it would be better to check them up case-by-case. Beagel (talk) 17:58, 18 March 2015 (UTC)

Down to 60. -- Magioladitis (talk) 13:41, 19 March 2015 (UTC)

Down to 28. -- Magioladitis (talk) 20:40, 23 March 2015 (UTC)

Down to 0. -- Magioladitis (talk) 20:18, 11 April 2015 (UTC)

John Butters Hydroelectric Power Station

There is a issue concerning usage of the infobox for the John Butters Hydroelectric Power Station. Beagel (talk) 09:40, 21 June 2015 (UTC)

Creating an extra parameter by using the 'extra' field

Hey. Looking at this article for example, does anyone know how to add the PUCSL License: EL/GS/14-04 as a new parameter by utilizing the extra parameter? Nesting? I vaguely remember that we did such a thing in an article somewhere, but I cant find it. Thanks in advance! Rehman 06:47, 6 November 2015 (UTC)

User:Rehman, not sure what you are asking. when I see that article, I see the text in question at the bottom of the infobox. are you asking to add a new parameter with a label, like the |blank_name_sec1=/|blank_info_sec1= parameters in {{infobox settlement}}? or do you want |PUCSL License=EL/GS/14-04 to work? Frietjes (talk) 00:17, 14 November 2015 (UTC)

Frietjes. Latter, but with a slightly different working. I want to know if there is a way to add an additional custom label and info (using the existing extra parameter), but without making any modifications to the existing power station infobox... Can we use embed or one of those magical codes? Rehman 15:45, 14 November 2015 (UTC)

User:Rehman, if you want to embed an infobox inside of this one, without making any changes to this infobox, you need to embed another infobox

{{Infobox power station
| extra = {{infobox|child=yes
| label1 = PUCSL License
| data1 = EL/GS/14-04
}}}}

not recommended if you are going to do this more than once. better would be to add |extra_label= and |extra_info= as free form parameters. Frietjes (talk) 15:53, 14 November 2015 (UTC)

Thanks Frietjes, this is helpful. I like the idea of having the extra label/info fields, but lets wait and see if more people think that's a good idea. If there is sufficient consensus from the key folks on these infoboxes, I am towards having whole customizable section at the bottom of {{Infobox power station}} and {{Infobox dam}} (before "website" and existing "extra" field, which I believe should not be modified to support existing embedded infoboxes). By a whole section, I mean a customizable section header (like the existing "Power generation"), together with about maybe 4 customizable labels and parameters. This is particularly useful for localized information, such as license numbers from certain local regulatory bodies, and so on. If I remember correctly, UK has some grid reference for power stations, which would fit well in these extra parameters. Cheers, Rehman 16:16, 14 November 2015 (UTC)

moved your "ping: NortyNort, Beagel" to here since it only works if it's added at the same time as your dated signature. Frietjes (talk) 17:27, 14 November 2015 (UTC)

@Rehman: I am not convinced if we need this addition; however, if there is consensus for it, I will not voice against it. From the technical side, the solution proposed by Frietjes is probably the best one. Beagel (talk) 17:42, 15 November 2015 (UTC)

Storage capacity integrated in PS

I have added ps_storage_hours because it is becoming an important factor in last generation CSP plants. And new legislation in Europe is giving/would give incentives also to renewable power deferred delivered thanks to plant integrated storage capacity, i.e. a PV plant could deliver power also after sunset, in the night. So integrated storage is becoming a general technology factor, at least for intermittent renewable sources. Usage example: Crescent Dunes. --Robertiki (talk) 15:58, 13 March 2015 (UTC)

As you see in the example, there is also a energy value, i.e. 1100 MW·h . I think that the hour unit is more direct. --Robertiki (talk) 16:04, 13 March 2015 (UTC)

I oppose this unless there is strong consensus towards it. It will be very rarely used, and is something that doesn't belong in the infobox, IMO. Rehman 13:39, 17 March 2015 (UTC)

Why should it be very rarely used ? It would be the value that separates the renewable conventionally dispatchable power plants from intermittent sources. It so important that lawmakers want to push even the owners of photovoltaic systems to implement some level of energy storage. Instead of following a new infobox upgrade, let us start now. And anyway, many solar thermal power plants have already storage. CEC (Califonia Energy Commission) has mandated that future thermal solar power plants should have storage. And there are many practical reasons for wind parks to follow suit, becoming so wind power plants. A first project example for wind is a power island with the wind turbines placed along the ring. --Robertiki (talk) 14:25, 22 March 2015 (UTC)

I agree that it is a major subject in RL, but here on wikipedia, that information is very rare. If there is a considerable number of articles that has such information (say, at least a few dozen?), then I'd support it, but right now, the information is not something that is easily available to us. Do correct me if I'm wrong. Nevertheless, adding the field is not a major task, and would not effect the entire template. So no need to rush along with the general cleanup that's going on (which seems to be mostly done now). Rehman 14:54, 22 March 2015 (UTC)

I agree that the information is available mostly (only ?) for solar thermal power stations (but it should also be available for pumped storage power stations - capacity is not unlimited). So here is a number of articles with that information: Solana Generating Station with 6h, Andasol Solar Power Station with three units 7.5h each, Extresol Solar Power Station with three units 7.5h each, KaXu Solar One with 2.5h, Manchasol Power Station with two units 7.5h each (article to be created. atbc), Valle Solar Power Station with two units 7.5h each, Termosol with two units 9h each (atbc), Astexol 2 with 8h (atbc), La Africana with 7.5h (atbc), La Florida with 7.5h (atbc), La Dehesa with 7.5h (atbc), Puerto Errado with to units 0.5h each, PS20 solar power plant with 1h, Gemasolar Thermosolar Plant with 15h, PS10 solar power plant with 1h, Delingha Solar Thermal Power Project with 7.5h (atbc), Greenway CSP Mersin Solar Tower Plant with 2.5h, Archimede solar power plant with 8h, Ouarzazate solar power station with 3h, Ashalim power station with 4.5h, Crescent Dunes Solar Energy Project with 10h, Diwakar with 4h (atbc), Arenales PS with 7h (atbc), Casablanca with 7.5h (atbc), Khi Solar One with 2h, Bokpoort with 9.3h (atbc), Gujarat Solar One with 9h (atbc), Alba_Nova_1 with 1h, Airlight Energy Ait-Baha Pilot Plant with 5h (atbc), Arcosol 50 with 7.5 (atbc), Aste 1A with 8h (atbc), Aste 1B with 8h (atbc), eCare Solar Thermal Project with 2h (atbc), Holaniku at Keahole Point with 2h, Ilanga I with 4.5h (atbc), Jemalong Solar Thermal Station with 3h (atbc), Jülich Solar Tower with 1.5h, Kathu Solar Park with 4.5h (atbc), Lake Cargelligo Solar Tower with 12h (atbc), Llo Solar Thermal Project with 1h (atbc), Nevada Solar One with 0.5h, NOOR I with 3h (atbc), NOOR II with 7h (atbc), NOOR III with 8h (atbc), Pedro de Valdivia with 10.5h (atbc), Planta Solar Cerro Dominador with 17.5h (atbc), Redstone Solar Thermal Power Plant with 12h (atbc), Rice Solar Energy Project with 8-10h (atbc), Xina Solar One with 5h (atbc), ILIS project (atbc) as per following source [ACCIONA incorporates energy storage into a grid-connected PV solar plant for the first time in Europe]. If the editors see no field they are not suggested to search the parameter, that may be found, sometimes with some effort. Counting only the existing articles, there are already more than twenty that I have to update with the new parameter. Should we wait more ? I have freezed adding new solar plants articles because the Infobox, which requires me some effort to compile, has some missing parameters. One is capacity. The other is the solar field aperture area, more usefull than the number of mirrors or collectors. And then there is the classification problem: hybrid, augmented or thermal-boosted, ISCC, and so on. Beagel suggestion that there may be more sections to be represented in the infobox could solve my dilemma. So now I am missing only one parameter: percent of solar contribution in hybrid plants, say solar_contrib_percent ? Jumping to another branch, I would also underline a missing sector, if pumped storage has a place here, why not other technologys as per List_of_energy_storage_projects? (see how the have mixed pure storage facilities with power stations) --Robertiki (talk) 17:00, 22 March 2015 (UTC)

Robertiki, sorry for the late reply. I was leaning towards having a solar_storage_hours only, since almost all you mentioned are solar power stations, but after looking at all the battery/other storage plants at List of energy storage projects which you provided (I didn't know they existed!), I agree with you a for having a ps_storage_hours. Do feel free to revert my revert to add them back, or if you don't read this message by later today, I shall add it back by EOD. Best regards, Rehman 02:49, 4 April 2015 (UTC)

@Rehman:, just added.--Robertiki (talk) 02:59, 6 April 2015 (UTC)

Hi Robert. Could you also update the documentation for those please? Rehman 06:36, 19 April 2015 (UTC)

Hey Robert. I have removed two fields which you added about 7 months ago along with the above storage field. Those were never mentioned in the documentation page, nor do I recall a discussion about it. I went ahead and removed it only because of the fact that it was never in documentation, and hence was never probably used by anyone. Please do reply if you wish to add it back. Personally, I am leaning towards not adding it, but I'm open for discussion. Regards, Rehman 14:07, 13 November 2015 (UTC)

@Rehman: Crescent Dunes Solar Energy Project used both paramters. I added a discussion Template_talk:Infobox_power_station/Archive_3#Solar_Heliostats_and_linear_parabolic_mirrors_to_active_surface_and_solar_resource on 6 April 2015. I repeat (copy) it here, because it was archived.

I am talking about the old csp_units that have disapeared, while the heliostats number had survived. I thought it over, and instead of restoring the csp_units number or change the description of solar_csp_heliostats to 'number of heliostats or parabolic throughs', I propose to change it to solar_field_aperture (area). The number of mirrors is not of particular interest. Mirrors are not standard; either heliostats or parabolic troughs come in a variety of sizes, so knowing their number and size can be an interesting detail in the text, but the real significant value (and 'condensed' information) is the global capturing area, not to be confused with the site area. Another very important information, critical and typical of every solar site is the solar_resource (kWh/m2/year or kWh/ft2/year units).

I took a look at the whole Solar section and here are some thoughts, just in time before the number of articles about solar plants booms:

• section name: better naming could be "Solar field", because we may have just a solar field, and not a complete conversion process, like in a PV unit or a wind turbine
• solar_cpv_concentration applies also to CSP technology so name should be solar_concentration_ratio
• solar_csp_heliostats is specific only to one of the four CSP technologies. Dish Stirling have "dishes", Solar tower have "heliostats", Fresnel reflector have "long linear flat mirrors" and Parabolic trough have, guess, "troughs". Dish size, heliostat size, mirror size and trough size vary so knowing there number is not so characteristic. And anyway, what is interesting about Dish Stirling counting, finds place in the ps_units_xxxx parameters. The other three technologies have a steam turbines units count. Either solar_csp_heliostats should be dropped or changed to a generic solar_csp_collectors. I would prefer introduction of solar_field_aperture, so I suggest a compromise (in the future we could drop che collector count), adding both (and removing solar_csp_heliostats)
• solar_resource, as said, should be a must; energy production changes drammatically with same units, same nominal power, but different location and this information should really jump out in the infobox.

--Robertiki (talk) 23:49, 7 February 2016 (UTC)

Hello Robertiki. So if I understand you correctly, you wish to:

1. Change the section header "Solar farm" to "Solar field".
2. Rename solar_cpv_concentration to something like solar_concentration, so that it can be used with other technologies.
3. Rename solar_csp_heliostats to something like solar_csp_collectors, for same reason as above.
4. Add something like solar_site_resource for a "kWH/m2/year" type value.
5. Add something like solar_site_aperture for a (insert example here) type value.

Am I correct? If so, I personally agree with all above. It is very useful. To add to the bucket of changes, I propose removing solar_cpvt (which is a Yes/No field). As filling solar_type covers this field as well. If there is no objection in say, about a week, I would be glad to do all the changes above. Regards. Rehman 08:59, 8 February 2016 (UTC)

Very well, and I think it's ok to remove solar_cpvt (was it used ?). --Robertiki (talk) 18:20, 8 February 2016 (UTC)

One correction: it's solar_field_aperture not "site", where "field" is the field of collectors. --Robertiki (talk) 18:24, 8 February 2016 (UTC)

Okay. I stated "site" only to neatly align with the prefixes of neighbouring parameters. Are you sure "site" cannot be used? Even with updated documentation? To me it sounds like the same thing... Just saying... Rehman 03:17, 9 February 2016 (UTC)

Problem with "decommissioned"

We really need a new status, "shut down", and maybe a date field for it. The problem is that for nuclear plants, decommissioning starts with shutdown, and can take 60 years and cost a billion dollars.[2] So we need something for the status of nuclear plants after they've been shut down and before they have been decommissioned. This was discussed in 2011 (it's in the archives) but there was no resolution. Kendall-K1 (talk) 04:15, 31 January 2016 (UTC)

The current status should be added to the 'status' field but I agree that we need to make distinction between 'closed' and 'decommissioned'. I propose to add an additional field 'closed' before the field 'decommissioned'. Beagel (talk) 09:27, 31 January 2016 (UTC)

Suggesting 'under decommissioning'. Closed is the same as 'mothballed'. And also a nuclear plant may be 'mothballed', for what ever reason. --Robertiki (talk) 23:58, 7 February 2016 (UTC)

To me "mothballed" suggests it could be turned back on at some point, while "closed" is final. Kendall-K1 (talk) 00:06, 8 February 2016 (UTC)

Exactly. It's a "fixed" stage. And a nuclear plant which has not "started" decommissioning work, could be turned back. Instead, decommissioning could be seen as a long process like 'construction', which takes some time: "under construction". --Robertiki (talk) 04:23, 8 February 2016 (UTC)

I agree with Kendall-K1 and Beagel, that we need a "closed" field. But...
|P=Proposed
|U=Under construction
|UC=Under construction
|M=Mothballed
|C=Cancelled
|O=Operational
|D=Decommissioned

...these are the parameters currently used (reordered for ease of understanding). We can't use "C", since it's already used. So we can either just use "Closed" when needed and leave the other codes as it is, or just completely remove the autofilling feature altogether (requires another bot sweep). If the earlier, we could update the documentation page to something like:

• Status of the project. Such as:
  Proposed, Under construction, Mothballed, Cancelled, Operational, Closed, or Decommissioned.

Those who like to try magic can also used the codes... Thoughts? Rehman 08:41, 8 February 2016 (UTC)

Whatever we do, the documentation needs to be updated. Now it only says to enter one of the codes. It does not say that you can enter whatever you want, and it doesn't have to be one of the codes. Kendall-K1 (talk) 12:41, 8 February 2016 (UTC)

What so bad with: |UD=Under decommissioning? :-) --Robertiki (talk) 18:14, 8 February 2016 (UTC)

That seems good to me. Maybe the codes must be unique in the first letter? In that case we have 20 letters left, I'm sure we can agree on one. Kendall-K1 (talk) 11:22, 9 February 2016 (UTC)

I guess testing is done on the string level. Anyway: |BD=Being decommissioned ? --84.222.99.110 (talk) 04:41, 10 February 2016 (UTC)

I personally like BD. Rehman 14:36, 10 February 2016 (UTC)

So now that we have BD (thanks!) don't we still need "closed"? I'm thinking of Vermont Yankee. It no longer produces power, is not really mothballed, but has not yet started the decommissioning process. Kendall-K1 (talk) 14:44, 20 March 2016 (UTC)

I fully agree that we still need "closed". If there question is about letter, maybe we could mark it with CL? Beagel (talk) 17:07, 20 March 2016 (UTC)

Collector area versus aperture area

Naming collector area such as in solar_collectors_area, is confusing for solar parabolic trough system. The collector area of a parabolic trough is much more than the aperture area. Only with PV collectors and heliostats, they are the same. That is the reason why I prefer solar_field_aperture. --Robertiki (talk) 01:27, 26 March 2016 (UTC)

Here an example. (RP 2) we have four mirrors in section, for a length of 1324(uppermost) + 1400(uppermiddle) + 1400(lowermiddle) + 1324(lowermost) = 5448 mm. That length by 1570 mm section size yields the collector area. But the "aperture width" given is only 4980 mm and if you multiply by 1570 mm you obtain a aperture area much smaller. --Robertiki (talk) 01:52, 26 March 2016 (UTC)

Oh boy. I thought twice about this, but finally went ahead with renaming it to solar_collectors_area, as there was no response to this question which I have asked earlier. Hence I assumed that you had no issue with it sorry I misread that old post. Regardless, your explanation makes a lot of sense, and I had overseen this. Thanks for raising it up again. I will do the necessary fixes. While we're at it, do you think it is worth having both parameters? As in, solar_collectors_area and solar_aperture_area? Personally, it seems to add value, but I'm not sure if such information is readily available in most cases. Rehman 14:54, 26 March 2016 (UTC)

One brief note: we where already talking; before doing the subsequent changes, you could had given a one day advance notice. It is not a requirement, I like bold editors, but it would had saved time (yours and mine :-).

Anyway, the reason is that the guys that work at NREL and some involved producers, prefer the "aperture" data, that means some searching for the real collector area. I could accept your proposal, because the collector area gives a feedback about how much "material" is involved in the construction. On the other side, if I want to estimate the useful collected nominal peak power (at 1 kW/m2) of the parabolic mirrors I need to know the smaller aperture area, which, I have to calculate otherwise starting from the distance of the focal point from the parabolic profile of the mirror and the mirror total length. Having both data could be interesting, but I feel that the infobox is risking to be cluttered, and there other missing facts that could find place. If it was a infobox specific for solar energy, I would say Yes. But it is a general infobox and hybrid power systems could get very long infoboxes. So, I think that we have to make a choice and let the specifics in the article. The most easy data to find is, as said, the aperture width and apertura area, and that, I feel, closes the choices to aperture. Personally, I am planning to make an article that describes all the SCA models I find, with the relevant specific data, and use that data in the power station articles to calculate the collector area. Hmmm... a collector model parameter could have place: the same logic as ps_units_manu_model. And we still have to tackle the biggest problem (that causes more confusion to "the folks" than the above discussion of what is a power unit in a photovoltaic system), and that is how to correctly describe a ISCC plant (which is solar like a car is electric only because of the starter motor.

I made some points here. A updated summary (Infobox has changed from that comment) follows:

There is some classification to do. There are three classes of mainstream hybrid solar thermal/thermal power station:

• solar thermal (SEGS type) where there may be up to 10% contribution from backup gas burners to a primarily solar plant
• hybrid solar thermal and thermal power (i.e.ISCC for example) where there may be up to 10% contribution from solar energy to a primarily fossil thermal plant
• hybrid solar biomass plants (Termosolar Borges) where there may be 50% contribution solar and 50% contribution from biomass

With all types we have sharing of the steam turbine, generator and power step-up transformer.

• if solar contribution more than 80% --> solar thermal plant (i.e. SEGS), definition as solar plant is acceptable
• if solar contribution less than 20% --> solar integrated thermal plant and should be name as thermal power station
• if solar contribution is more than 20% and less than 80% --> hybrid solar/biomass or solar/thermal plant and may be named a hybrid power plant

Still thinking. --Robertiki (talk) 00:14, 28 March 2016 (UTC)

ps_units_operational in PV farms and solar_elements collectors

In Copper Mountain Solar Facility and other PV farm articles ps_units_operational is used to count the PV modules, as in "775,000 First Solar panels". I would propose that what is to be counted as ps_units_operational are the number of inverters, from which the power flows out to the power transformer. A PV module alone is of no use. Documentation could be changed as:

ps_units_operational

Number of currently operational turbines/generating units, or inverters for PV plants. Not applicable for pumped-storage power stations.

that is adding the words: ", or inverters for PV plants." Following the wikilink, the reader has the explanation of what are the inverters. --Robertiki (talk) 07:50, 21 March 2016 (UTC)

And solar_csp_collectors could be used to count the modules. Damned! I guess we should change solar_csp_collectors to solar_elements solar_collectors (why specify selectively csp ?). And documentation changed as:

solar_collectors

Number of heliostats or collectors or PV modules.

that is adding the words "or PV modules." I am not sure. Any suggestions ? --Robertiki (talk) 08:02, 21 March 2016 (UTC)

Using ps_units_operational to count solar modules does seem wrong. I don't think using it to count inverters is any better. There are systems that have one inverter per module, for example, (not at utility scale yet) so it would amount to the same thing. I don't think the concept of "units" is applicable to solar plants. The metrics that make sense to me are collector area, max AC power output (DC is useless), and average power output (usually given as some number of watt-hours per year). Kendall-K1 (talk) 10:31, 22 March 2016 (UTC)

One inverter per module is not exactly what I would define as utility scale (as you have noted). Consider the name of the infobox: "power station". Now let's try to outline a conventional power station: some primary power generation elements, each followed by a number of conversion elements (from one type of primary energy to other type of energy) which usually ends with a electrical terminal block, from which wires transfer power to a common step-up transformer (but there could be more transfomer). A summary table:

- boiler -> (steam turbine-generator) -> step-up transformer

- dam (captures water) -> (turbine-generator) -> step-up transformer

- sun concentrator (captures heat) -> (steam-turbine-generator) -> step-up transformer

- photovoltaic module -> inverter -> step-up transformer

- (n.a.) -> (wind turbine-generator) -> step-up transformer

The table above is a little little stretched: for PV, because it is the only system with the second last component input already electricity, albeit in DC, and for wind, because the first element is missing or integrated in the second. Usually the element that is called unit is the one that get's connected to the step-up transformer (a small to medium power plant usually has only one step-up transfomer, at which, output is measured as the power station "net" total power output).

In summary, with PV we have three electrical power values, instead of the usual two (gross and net are the two usually two reported, with the net value missing), and they are: gross DC power (at the module), gross AC power (at the inverter), net AC power (after the step-up transfomer). But if we consider only AC power (putting DC power as steam, as a different carrier of energy from AC power), we can talk about gross and net power. And by the way, when power plants are compared with photovoltaic farms, we should always compare the output at the step-up transformer (that also you seem to have forgotten): before (gross) or after (net).

So, definitely the module count should not be in the ps_units_operational. But, maybe, the inverter count (as a unit), could stay in, giving a point where you take the measurement of gross AC output. The module count could instead have the proposed allocation. I agree that the element count has little interest (collector area is more useful), but others could like to use the value for estimating cleaning or other management costs ? --Robertiki (talk) 18:20, 22 March 2016 (UTC)

I disagree with changing the usage of ps_units_operational, as that field should have the final individual output units along with the corresponding wattage (as with all other power station types). Moving the intended content from here, to solar_collectors would mean more unnecessary article sweeps (for parameter updates), and also would make the solar section the odd one from all the others, creating confusion with folks not closely following the template discussions. If necessary, we could have a separate parameter for inverters. Rehman 03:20, 25 March 2016 (UTC)

I agree with: “[ps_units_operational] ... field should have the final individual output units along with the corresponding wattage (as with all other power station types)”

Where do we have the final individual output of a photovoltaic system ? What use have we of a string of modules without a inverter ? Also more from a utility point of view (the infobox is about power stations) ?

Therefore a “photovoltaic unit” comprises a string of modules and an inverter, and the output is at the inverter terminals. The gross wattage of a power station is the sum of the wattage at the unit terminals, and for a photovoltaic system that is the inverter terminals (sum of what is also known as ACwattages of each inverter, not the PV modules output). Therefore the inverters are the output units of a PV system.

Putting the number of PV modules as operational units is like putting the number of boilers of a steam turbine as operational unit and that usage makes the photovoltaic systems “odd” (not the solar section).

The confusion with the folks is fault of the media, that far reasons beyond these talks, has difficulty to put the things right, especially in Europe. It is in the USA that we make a difference between DCpower (inverter input) and ACpower (inverter and PV unit output). A good documentation takes care of the folk's confusion.

From the infobox documentation: Number of currently operational [...] generating units. How is a PV operational unit ? A string of modules plus one inverter. --Robertiki (talk) 01:16, 26 March 2016 (UTC)

I disagree. The individual PV panels are final individual output units. They are non-variable and has a stipulated capacity for each unit. The inverters are just a mid-stage to convert the electricity. Whereas panels-per-inverter varies, and is something like step-up transformers per a bunch of wind turbines, in a large wind farm. Either way, we need more folks to share their views on this (ping User:Beagel). On a separate note, we can have another separate field for inverters though. Rehman 15:26, 26 March 2016 (UTC)

We are stuck. I the see the PV modules as the boilers in a thermal power group (steam or DC current, for the utility, it is the same: unusable without further transformation). The inverters do much more as simply converting the DC current to AC current. The inverters deliver a stable voltage and phase angle, which are crucial to a successful grid connection. Only by complementing the PV module string with a inverter we have a useful power unit. I insist; power station infobox is about power stations. At these point, we should wait other editors, possibly experts in the utility field (sorry, but please no PV installers without grid or power step-up transformer selection knowledge). If "the folk" is confused, a encyclopaedia serves to put the record straight, not to follow the urban legends or the "was always done so", as news media has done. --Robertiki (talk) 00:44, 28 March 2016 (UTC)

Cost of plant conversion to USD

I have added some information to the cost parameter documentation. I did not know that there were converter templates, such as {{To USD}} and {{INRConvert}}, so I though it would be useful to point to them and give some advice. --Robertiki (talk) 01:01, 4 April 2016 (UTC)

Just made an example in Kudankulam Nuclear Power Plant article. --Robertiki (talk) 01:11, 4 April 2016 (UTC)

Caption2 should ignore missing location_map argument

Hi. I have a minor technical request. The argument for caption2 fails silently when {{{location_map}}} is empty.

Currently, it reads like this:

| caption2      = {{#if:{{{location_map_caption|}}}|{{{location_map_caption|}}}|Location of {{{name|{{PAGENAME}}}}} in {{#invoke:Location map|data|{{{location_map}}}|name}}}}

Instead, it should handle an empty location_map argument. This can be done by adding {{#if:{{{location_map|}}}| at the start and }} at the end. Specifically:

| caption2      = {{#if:{{{location_map|}}}|{{#if:{{{location_map_caption|}}}|{{{location_map_caption|}}}|Location of {{{name|{{PAGENAME}}}}} in {{#invoke:Location map|data|{{{location_map}}}|name}}}}}}

Without this change, an empty location_map argument will fail in the part of the line that reads {{#invoke:Location map|data|{{{location_map}}}|name}}. This will call Module:Location_map with a literal argument of {{{location_map}}}.

In the current form, there are several dozen power station pages that fail silently because they don't pass {{{location_map}}}. The below is a listing of 12 pages, but there are at least several dozen that use this template without a location_map argument.

Three_Gorges_Dam	Manapouri_Power_Station	Koeberg_Nuclear_Power_Station	Bohunice_Nuclear_Power_Plant
Lots_Road_Power_Station	Chapelcross_nuclear_power_station	Solar_Energy_Generating_Systems	Salem_Nuclear_Power_Plant
Laguna_Verde_Nuclear_Power_Station	Hearn_Generating_Station	Ekibastuz_GRES-2_Power_Station	Monticello_Nuclear_Generating_Plant

Again, this is a silent error, and nothing is visibly shown to the user. However, I think it's worth making the change, if only for the sake of better form.

I've made the proposed change to the sandbox here: https://en.wiki.x.io/wiki/Template:Infobox_power_station/sandbox. Let me know if you need any other information. Thanks. gnosygnu 00:30, 3 May 2016 (UTC)

done. Frietjes (talk) 00:37, 3 May 2016 (UTC)

@Frietjes: Thanks! gnosygnu 21:50, 3 May 2016 (UTC)

Extra parameter sample not working

Following the link "Example" in the extra parameter documentation I don't see any infobox. Something is wrong ? --Robertiki (talk) 18:57, 15 May 2016 (UTC)

India currency conversion

@Rehman: I see [3]. India has a strange number system and requires a specific currency converter. I had to work hard to understand that problem and thought to help other editors with a practical solution. The examples are therefore needed to explain the different approaches. --Robertiki (talk) 18:31, 15 May 2016 (UTC)

Different issue but is it really necessary to convert euros to dollars while there is no conversion other way around? Beagel (talk) 15:53, 16 May 2016 (UTC)

I was editing Kudankulam Nuclear Power Plant and other indian plants and found difficulties to have a reliable value in dollars. Here and here some aspects. The dollar and euro conversion instead is no problem. Changing example to:

Total cost of development. When the given currency is that of a not US plant country, consider using following format: country-currency (US${{To USD|country-currency|country-name}}). For India consider using {{INRConvert|value|c|2}}.

Example 1: kr92.50 million (US${{To USD|92.5|Denmark}} million) which results in kr92.50 million (US$14.71 million)

Example 2: {{INRConvert|17000|c|2}} which results in ₹17,000 crore (US$2.04 billion)

I prefer a standard comparing currency. I guess the dollar is a good one. --Robertiki (talk) 15:47, 17 May 2016 (UTC)

Encourage auto suffix

@Rehman: I see [4] and [5]. Why discourage auto suffix ? I recall you removed it in 2014 and after User:Beagel noticed that it was missing, last year, I restored it. I recall, for convenience, your words:

I believe this creates more difficulty than simplifying things, for most users. Someone who is not much of a Infobox power station expert (like everyone in this talkpage), would like to just copy the skeleton, and then fill in, in probably GW or even KW, and have their own preferred linking. But enabling that automation would just create stress on having to come back and understand the various formats needed to make it work. Initially, I was against all automation in the template, but realized that automating a more complex thing would actually be helpful (like the nuclear portion).

I understand that you don't like automation. Ok. So its time to talk about it.
I don't see nothing bad in auto suffix-ing. If the user forgets the unit and has written, for example, a kW value, than auto-suffix would help him to notice that "Current gross installed capacity in megawatts ...", that is that the mandatory unit is MW. And all that is easy for the user. He has to do "nothing" to use auto-suffix, instead like in auto-filling, where you have to find the correct code. What I like of auto-suffixing is that the unit is also correctly linked to the unit page description, without user knowledge of wiki-linking. And I like that it is the same unit. not MWe as here here or MW as here. --Robertiki (talk) 16:56, 15 May 2016 (UTC)

I also prefer that the auto suffix remains. I don't know how it was with the latest version but I remember that in some earlier versions if unit was added to the value, it overrun the auto suffix. So, I don't see any problem or controversy here. As for units, I would discourage of usage of kW or GW for capacity instead of standard MW. I think that also generation should be standard GWh. Beagel (talk) 21:38, 15 May 2016 (UTC)

I recovered the old code, the latest version is the same: if unit is added, it overruns the auto suffix. --Robertiki (talk) 14:09, 16 May 2016 (UTC)

In that case I don't see any benefits of removing the auto suffix. Beagel (talk) 15:48, 16 May 2016 (UTC)

Hey. Sorry for the late reply. The auto suffix was removed with the help of some other editors using this and this categories (now deleted). Reason behind this is because there were around two dozen articles which the editor didn't actually have an idea of what the value is (KW, MW, etc) and filled it with some random number (of probably something else), meanwhile there were also a number of other articles that clearly did not mean MW, but the infobox automatically added the MW suffix.

What I am trying to point out is, the majority of new editors really don't bother to read the documentation in detail, and instead add the values based on the basic idea they get when reading the parameter name itself. So when it comes to the auto suffix, this actually creates more harm than good. Roughly about 400 articles (which used auto suffix) were reviewed, and changed to manual. And just for the record, I am strongly towards automation and efficiency, but not at the expense of quality and accuracy. Cheers, Rehman 13:41, 17 May 2016 (UTC)

It is just because the majority of new editors really don't bother to read the documentation that the auto suffix option is useful. The new editors don't know (bother) where the infobox documentation is. But, at least, they will look at the result of their editing. And see that the intended, kW value is reported as MW. Their logical reaction would be to add the explicit unit (nnnn kW) or, if more diligent, search the documentation or ask for help (info). The charm of auto suffix is that if the unknowing user want's kW (for what ever reason), he may have it. And that intelligent user's know that there is something to learn about why the MW unit pop's up in the infobox.

About the user's filling with some random number (of probably something else), it won't change if a MW is added. Wrong is wrong, with or without MW appended. --Robertiki (talk) 16:24, 17 May 2016 (UTC)

I agree, lets restore the auto suffix option. Beagel (talk) 11:21, 5 June 2016 (UTC)

I didn't expect any concerns to be raised with the removal of the autosuffix, hence I went ahead without discussions. Since there is more support towards having it, I have restored. Cheers, Rehman 11:50, 5 June 2016 (UTC)

Changed Nameplate capacity to Operational capacity

I changed the ps_electrical_capacity caption from Nameplate capacity to Operational capacity to resolve what is intended for installed capacity in the documentation. It is explained that additional units under development are not to be added. But I feel it should also explicit that decommissioned units are excluded from the sum, to be consistent with the annual generation value. --Robertiki (talk) 04:39, 11 June 2016 (UTC)
Now I have doubts about the planned capacity for new plants reading as Operational capacity.--Robertiki (talk) 14:28, 11 June 2016 (UTC)

Do we need the bright yellow?

The bright yellow does rather overpower articles containing this box. Is it really necessary? --Money money tickle parsnip (talk) 06:13, 28 March 2016 (UTC)

Hi MMTP. If I remember correctly, it had been that colour since many years now. I have no issue with it being changed, as long as there is a vote from the editors here (and perhaps the Energy WikiProject), just so that it wont be changed again in a short while. Kind regards, Rehman 13:58, 29 March 2016 (UTC)

It is not bright yellow. It is gold. What do you mean overpower? Have a color in mind ? --Robertiki (talk) 10:06, 31 March 2016 (UTC)

Maybe we could just remove the color? I personally don't see any added-value of having it. Beagel (talk) 21:41, 15 May 2016 (UTC)

@Money money tickle parsnip, Rehman, and Robertiki: I propose to start the formal RfC procedure if we should to keep the current background color scheme or should we remove it. Any comment about this before filling the request? I would like also ask which venues should be notified about the RfC. WP:Energy, for sure, but is there any centralized notice board about infoboxes? Template:Infobox maybe, or is there any better venue? Maybe Frietjes, Magioladitis or Plastikspork can recommend something? Beagel (talk) 17:50, 31 May 2016 (UTC)

this is probably the best place for discussing changes to this template. but, we should do our best to make sure the discussion is well advertised. I would support either (a) light grey ala Template:Infobox building, or (b) say lavender ala Template:navbox, or (c) a thin grey line ala template:infobox settlement. Frietjes (talk) 18:44, 31 May 2016 (UTC)

I support syncing the colour with that of {{Infobox dam}}, which is a bit closer to {{Navbox}} which Frietjes mentioned above. Rehman 23:47, 31 May 2016 (UTC)

That's

skyblue

. --Robertiki (talk) 00:19, 1 June 2016 (UTC)

Here some samples from around: fr:Centrale nucléaire de Flamanville, fr :Centrale hydroélectrique d'Edolo, fr :Ferme solaire Topaz, es :Central nuclear Santa María de Garoña, es :Central Hidroeléctrica Simón Bolívar, es :Gemasolar, it :Centrale nucleare di Hamaoka, de :Kraftwerk Jänschwalde, de :Kernkraftwerk THTR-300. Some Lists of colors, X11 color names and Web colors. And some colors the template had in the years:

#999900

#BBBB22

lightsteelblue

#CCF

#FFFFCC

Orange

#DDDD44

and a code easy to remember:

#ffdead

It could also be chosen a different color for each energy source. --Robertiki (talk) 00:12, 1 June 2016 (UTC)

On second though, I am not happy about discussing about colors. From the essay about colors, some feeds:

• ... near the bottom of the importance scale is the colour of template messages ...
• ... people frequently change the colour of templates, and those who decided on the colour in the first place frequently have an irresistible urge to change it back ...
• ... it was decided by a vote, which is widely considered a bad idea and even evil by some ...

The actual color was a change done on 23 February 2014, by Rehman. It was a choice like another and I live with it. Before I go on, I want to stress that I am not implying that there is some edit warring, I see this as a polite debate.
As you see, I haven't made any choice. I have found some samples, but have no preferences above them. I have my preferences, but are unhappy about discussing them. I would find helpful a discussion about selecting colors that help who have color problems. But not so much for pure esthetic reasons, because ... beauty is in the eye of the beholder. So I feel ok if the request is about a choice about ligther colors, which helps who has contrast perception difficulties (but the selected gold, if a solid color, at least helps with greater contrast than other solid colors, but almost any watercolor type could go). And I feel that some people would appreciate gray colors because it costs less printing and give a predictable outcome.
More from the essay: Extensive discussion of such changes, too, is to be discouraged—ideally, to be avoided completely—though a little explanation and statement of opinion never hurt anyone, and may be a good idea. And: When the time comes around, chances are you'll be accustomed to the new colour and no longer care, .... That's true, and some people simply don't like changes. Other people, on the other side, find that consistency is boring. And now, one point that may help us: colour contrast is of particular importance to people with poor vision, including those who are colourblind. Please preserve the accessibility of Wikipedia, per the guidelines at WP:COLOUR.

• Ensure the contrast of the text with its background reaches at least WCAG 2.0's AA level, and AAA level when feasible (see WCAG's "Understanding SC 1.4.3: Contrast (Minimum)").

What I feel we need is the possibility of a user selected color scheme. So anybody would be happy. --Robertiki (talk) 15:26, 2 June 2016 (UTC)

I still prefer transparent infobox like {{infobox company}} but also unifying with {{infobox dam}} will be a progress as this infobox sometimes transcluded in the dam infobox, e.g. Ulla-Førre. I agree that color preferences is something we should avoid by deciding by votr, but definitely broader discussion is needed. Therefore, is there any suggestion were we should notify about this discussion (even if no formal RfC is not opened). Beagel (talk) 11:27, 5 June 2016 (UTC)

That is a valid reason (having the same color for consistency). But the blue of infobox dam is too dark. I would suggest changing both to:

#F0FFFF

that is Azure Mist

or:

#B9F2FF

that is Diamond

to enhance readability, especially when printing with not new laser B&W printers. --Robertiki (talk) 13:40, 5 June 2016 (UTC)

Since no one disagreed that the current colour is too strong, I went ahead and changed the colour to "a lighter version of the current colour" basing on the colour generation guide. We can of course change it later once we agree on one colour. On a separate note, {{Infobox dam}}'s colour is used in almost all other dam infoboxes in other Wikipedias, so I strongly oppose changing the dam infobox's colour. Cheers, Rehman 05:10, 16 July 2016 (UTC)

Annual generation

@Rehman: Sorry if I am bothering you again, but your changes have me puzzled. The documentation now reads:"Average annual gross power generation". You added (swapped previous) with "Adding the year in brackets is encouraged." I would instead suggest: "(at least a 5 year average)" or other time length. "Average" and a specific year are contradictory. Is it a "average" value or a "single year value" ? --Robertiki (talk) 13:29, 17 May 2016 (UTC)

Not at all. I have fixed it, thanks. On a separate note, I noticed ([6][7]) that you were testing an entirely new "year" parameter to be used with the ps_annual_generation parameter. Since the total number of characters in the annual gen field is no more than about 17 (10,000 GWh (2000)), do we really need a separate parameter? Rehman 14:10, 17 May 2016 (UTC)

It is a possibility. If one has the patience to calculate the average of 5 year (or more ?) of generation, he may use Annual Generation (ps_annual_generation), Otherwise he could fill ps_generation_year and ps_annual_gen_specific and obtain NNNN Generation, NNNN = year. The parameters are though to be alternate. For the year inclusion in the caption, the idea was taken from the de.wiki. --Robertiki (talk) 15:15, 17 May 2016 (UTC)

Why cant we simply use either the average or the specific-year value in ps_annual_generation, with simple text (whatever the editor prefers)? As we discussed here about 2 years ago, the template needs to have only the most essential parameters, so that the huge template skeleton need not have to be lugged around... With this edit, two new parameters are added, when the same outcome could be achieved by using the existing parameter. If you still like to add them, can we raise consensus first (only because it involves additions to the main template skeleton)? Cheers, Rehman 15:51, 17 May 2016 (UTC)

The problem is that the value in square brackets will kill the auto suffix function. As you may understand, I look forward to your other objection/suggestion. The drafted proposal is to retain Annual Generation when no ps_generation_year is given, otherwise the result is evident, with the year placed just before Generation. label94 would be deleted, label93 will take both coding. --Robertiki (talk) 16:10, 17 May 2016 (UTC)

Code picked up from Vorlage:Infobox_Kernkraftwerk, sample at the bottom of the page, fourth row from the bottom of the box, year is 2005 --Robertiki (talk) 16:00, 17 May 2016 (UTC)

Coding complete in the sandbox. Here four samples:

• with year and specific generation, no unit

| ps_generation_year = 2014
| ps_annual_generation = 9999

• no year and average generation, no unit

| ps_generation_year =
| ps_annual_generation = 9999

• with year and specific generation, with kWh unit

| ps_generation_year = 2014
| ps_annual_generation = 9999 kWh

• no year and average generation, with kWh unit

| ps_generation_year =
| ps_annual_generation = 9999 kWh
That's all! --Robertiki (talk) 02:21, 18 May 2016 (UTC)

Hmmm ... suggesting, changing Annual to Average generation, to clearly highlight the difference. In the documentation it could be explained that the 5 year average is more meaningful, but if the editor prefers to place a specific year value, it is wished that the year is specified. I hope that that answers what troubled you, I think, as also me. --Robertiki (talk) 02:41, 18 May 2016 (UTC)

@Beagel, Frietjes, Magioladitis, Plastikspork, and Rehman: The problem I wanted to address is to help/suggest the editors that don't or won't give a calculated average production (5 years ?) value, to at least state the production year and use a consistent unit (GW·h). All that without taking them away the freedom to choose otherwise. I addressed also the question that the field is only 17 characters long, by simply putting the year (and only if given) in the fieldname. I repeat: all autosuffixing is overridable. Nobody is forced to accept it. Nobody has to read the documentation. But who reads it, will make a more consistent job, without any effort. I have tested all options (with and without year, with and without ovverride). The year insertion works also if the editor want's to override only the unit choice. The problem is that, after the last changes, I have no feedback, aside Rehman, who as a stated position against automatism. The samples are here. Should I put the new code, now in the template sandbox, in the template ? Only one parameter is added: ps_generation_year. --Robertiki (talk) 16:07, 2 June 2016 (UTC)

I agree that it would be justified to have both options: average generation and generation in certain year. We have actually the third case when we have a planned annual generation but I think that Robertiki proposal solves also this issue. So I say, lets go forward with this change. Beagel (talk) 11:20, 5 June 2016 (UTC)

That is really a good idea! I have just added two more examples: one and two. --Robertiki (talk) 12:16, 5 June 2016 (UTC)

The documentation may read as:

Parameter	Description
End section (used by all power station types, including those not listed above)
ps_generation_year	Year of the following given annual generation data. Enter Planned if the given data is a planned estimate.
ps_annual_generation	Average annual gross power generation. For a single-year value, enter the year in the ps_generation_year parameter. GW·h suffix will auto added for values without units.

If consistency is required (i.e.: assurance that Planned is inserted, without spelling errors), coding change is required to expand a P parameter to Planned, as happens per the status parameter. --Robertiki (talk) 13:09, 5 June 2016 (UTC)

Other color sample:

Parameter	Description
End section (used by all power station types, including those not listed above)
ps_generation_year	Year of the following given annual generation data. Enter Planned if the given data is a planned estimate.
ps_annual_generation	Average annual gross power generation. For a single-year value, enter the year in the ps_generation_year parameter. GW·h suffix will auto added for values without units.

It has a code easy to remember. --Robertiki (talk) 13:47, 5 June 2016 (UTC)

Can we change the parameter names as:

• ps_annual_generation
• ps_annual_gen_year

To keep the prefix aligned? If you're worried that we already have some articles using the param, I can take care of that. Let me know. I will make the change in a day or so if there is no objections. Rehman 12:29, 14 July 2016 (UTC)

Done. Rehman 12:55, 16 July 2016 (UTC)

Oldbury gives incorrect location

Oldbury Nuclear Power Station This powerstation is not located in Gloucestershire, it is located in South Gloucestershire. That's not "the south of Gloucestershire", it's a separate and different locality. How do we fix the template to give correct information? DanBCDanBC (talk) 16:50, 13 July 2016 (UTC)

What is exactly the problem? The coordinates seem to be correct. Beagel (talk) 18:10, 13 July 2016 (UTC)

Talk better done here. --Robertiki (talk) 03:10, 17 July 2016 (UTC)

Changing parameters labels too much longer

A editor has changed a bunch of labels with much longer names. I open this section to discuss about the effects. --Robertiki (talk) 15:38, 18 February 2017 (UTC)

The shorter labels are better, so long as they aren't confusing. If the are confusing, we can always use {{abbr}}. Thanks! Plastikspork _―Œ^(talk) 17:56, 18 February 2017 (UTC)

I just spelled out a lot of abbreviation to help the reader. The reason I didn't use the abbreviations template is becasue it doesn't work for mobile users. Grapesoda22 00:05, 19 February 2017 (UTC)

Grapesoda22, you need to change your signature. It violates WP:SIGLINK. Plastikspork _―Œ^(talk) 00:06, 19 February 2017 (UTC)

I did add one. I don't know why the hell it isn't linked. That's not intentional. Grapesoda22 00:08, 19 February 2017 (UTC)

I fixed it. Grapesoda22 (talk) 00:10, 19 February 2017 (UTC)

Hi. I have restored the older version for now, as the full version is simply too long. I recall juggling words some year(s) ago (when designing this infobox) to figure out the shortest form, and this is what we settled with. Unless we come up with better words altogether, I don't think it is a good idea to put in the full form, for aesthetic reasons. Kind regards, Rehman 03:54, 19 February 2017 (UTC)

I agree with the shorter labels, the infobox should look like a table for fast consultations, if one wants to learn more, there is the full text on the left. Long labels are distracting, getting in the eye before the actual parameters. --Robertiki (talk) 11:34, 19 February 2017 (UTC)

Nuclear Power Plants: Status value when reactors operational, but not generating power for years ?

The infobox for a number of nuclear power plants, e.g. Onagawa Nuclear Power Plant lists one or more reactors as operational and has a blank 'status'. This gives the impression that the plant is generating power, but since these plants have not generated power for years, e.g. 5 years, this really gives an incorrect impression of the actual status of the plant. Since the article for these plants has no information regarding a (planned) decommissioning, such plants could (in principle) go online soon. So really none of the currently valid values for the status field can be used to accurately describe the year-long and currently continuing non-operational status of these plants. Another class of plants in this state have an infobox with a status field with a free text value, e.g. 'Out of service' (Fukushima Daini Nuclear Power Plant), which is an attempt to deal with the inaccuracy, but not one that is according to the documentation for the infobox. Also 'Out of Service' may not be descriptive for plants that have been taken off line for no technical reason related to the plant itself. So I think it would be useful with a new, additional value for the status, one that expands to something like 'Offline', be it due to a technical issue, or a political decision. What do other contributors think? Thanks. Lklundin (talk) 22:07, 15 February 2017 (UTC)

To the infobox of a plant which currently has status 'Out of service' since a point in time that rules out WP:RECENTISM I am appending 'for {{Age in years and months}}', with the date from which no reactor has been delivering power. For Fukushima Daini Nuclear Power Plant that currently comes out as 'Out of service for 5 years, 11 months', which I consider notable. Lklundin (talk) 07:04, 17 February 2017 (UTC)

You are right (I was just to open a section talk like yours). Especially nuclear plants, but not only, may stay operational, but not producing, for years. If there is no technical reason, there is already a value: M=Mothballed (haven't you seen it ? or understood ? ---> we need a definition wikilink). Mothballed goes well for any no technical, i.e. economic or political or what else, reason.

What is needed is a value for plants undergoing a long refurbishment, compliance or upgrading (improvement) stage. As is happening in Japan.

It should be noted that using a free text value is not that bad, especially if it follows after an anomalous condition of the plants. But I feel the need of a specific value, because, as well as Japan case is an extreme case, anyway, nuclear plants may have long production stoppages. I agree that that value usage should rule out WP:RECENTISM, i.e. applicable only if the works extend over a year (for example).

About Fukushima Daini Nuclear Power Plant, it is in a limbo. Not mothballed (it needs repairs) and not under compliance (so also the new value would not apply) and not sure if it is earmarked for decommissioning. It is abnormal for a nuclear plant owner to do nothing, so I would keep the free text. I like your suggestion of using for {{Age in years and months}}.

The new value should preferably have a different letter, so I would starting proposing Improving which would start with I. Status table would than be:

P=Proposed

U=Under construction

O=Operational

I=Improving

M=Mothballed

B=Being decommissioned

D=Decommissioned

C=Project cancelled.

Anther choice would be reconstruction or rebuilding which would get a R value. --Robertiki (talk) 16:37, 18 February 2017 (UTC)

@Robertiki: Hello and thanks for your long and helpful reply. I did see the 'Mothballed' value and thought of still functional T-34s that had undergone preparation for decade long storage after more modern equipment became available. But now that you mention it, I can see that 'Mothballed' applies also if it happened without a better alternative and thus with a time horizon that (in principle) could be quite short. So I agree that some additional explanation of the values would be helpful. Ideally, such a text could be automatically linked to the term as it appears in the infobox. A new value in the -ing form of a verb seems to me to suggest that there is an ongoing activity at the plant, which could assume too much. Maybe 'N' for 'Not operational' is sufficiently descriptive without making any assumptions on what will happen next. Lklundin (talk) 17:54, 18 February 2017 (UTC)

PS. On reflection, given The Murky Future of Nuclear Power in the United States and the ongoing Toshiba/Westinghouse developments it is not inconceivable that an operational plant's owner suddenly goes bankrupt, leaving the plant non-operational, with no actions that can be described as 'Mothballed' having taken place. I think such (possible) scenarios is a reason for choosing a new value that assumes little as to the reason of the plant being non-operational. Lklundin (talk) 18:07, 18 February 2017 (UTC)

Hi both. I personally like the idea of having an "Out of service since..." entry, as opposed to "Improving", as it covers a wider range of situations. Also, {{Age in years and months}} could also be used for cases like "Under construction since..." (via free text option), which is a great value addition. Rehman 04:19, 19 February 2017 (UTC)

@Rehman: Yes, the already in use "Out of service" (optionally with "since ...") is descriptive, yet generally applicable. I see from your comment to the below section that you actually contributed to this infobox from its beginning. So what do you think about the expansion of single-letter abbreviations given that the status already has O(perational) as a possible value? Thanks. Lklundin (talk) 09:38, 19 February 2017 (UTC)

Since changing the use of "O" is out of the question, we should be able to use "OS" or something for "Out of service". These codes will actually be used by just a few editors who bother to read the documentation (many others prefer to just type in whatever appropriate), so I believe we can go ahead with it without thinking too much about it. Let me know if you need any help adding the code. Cheers, Rehman 09:59, 19 February 2017 (UTC)

I don't think that 'Improving' is a good description. We can always add a free text like refurbishment, compliance or upgrading, what ever fits better in the certain case. Beagel (talk) 19:36, 1 March 2017 (UTC)

"Out of service" is too generic. A "mothballed" plant is also out of service. Let us classify "out of service" plants, and remember that "Status" is a parameter for all power plant types.

• 1) plant owners might decide to shutdown. but make provisions to ensure that the plant could be restored to service if needed, or if the market conditions change by either increasing revenue opportunities, lowering operating costs, or both. I.e. mothballed

Note: nuclear parlance use also "lengthy shutdown" but it is the same status and I don't see the need of a different value (reader understands the difference from the power type of a mothballed coal plant versus a mothballed nuclear plant).

• 2) plant is undergoing a lengthy reconstruction (upgrading power and efficiency values, newer or better security systems, for new more stricter rules or economic reasons, etc.). I.e. improving and that happens also to coal plants, for example.
• 3) plants is essentially abandoned (not only nuclear ones). For example owner suddenly goes bankrupt. But this is a rare case, and does not warrant a specific value. A free text value is suitable and more flexible. Anyway, if you like, we could introduce: A = Abandoned But that is not usually the case of a nuclear plant, there is always some housekeeping. It may happen if a nuclear plant was never loaded, for example, incomplete construction as happened to Montalto di Castro Nuclear Power Station, which was savagely scavenged.
• 4) nuclear plants are also described in a status of "permanent shutdown", but what should it mean ? It looks like closed or under decommissioning. But remember Garoña Nuclear Plant, that was given for dead and now is under preparation to operate. So permanent shutdown does not distinguish between mothballed or given up.

Fukushima Daini Nuclear Power Plant is an example of a plant that at first looks like abandoned or crippled, but it is not. It is looked after every day. It could also return operational, if local political stance changes, so I would say it is more like mothballed, at least until decommissioning works are started (it looks it is earmarked for decommissioning). If mothballed is not liked, a free text could be the choice. We sould not define a value for only a couple of plants, it would be more of a hassle than a useful shortcut. Any other conditions ? (not mothballed/improving/abandoned) --Robertiki (talk) 13:40, 19 February 2017 (UTC)

@Robertiki: I agree with you to the point that the different status values should ideally cover mutually exclusive states of the plant. Given the number of reasons why a plant may be non-operational, I think it is better not to choose a new value that assumes too much on the reason behind the non-operational state. I agree with your description of 'Mothballed' that deliberate action(s) to allow for later operations have to be involved. This rules out 'Mothballed' for plants that have simply been subjected to a controlled stop (whether planned or not), with a possibly short time horizon for its current state. Values such as 'crippled' and 'abandoned' seem very specific and probably also not WP:NPOV. The word 'shutdown' has for a nuclear reactor a specific meaning which is different from when the word is used to describe something else. 'Permanent' rules out all cases with a possibly short time frame for the current state. 'Improving' implies an successful, ongoing effort to change the state of the plant, also ruled out in the typical case that lead to this discussion. 'Housekeeping' similarly requires some activity. 'Lengthy' is redundant if we accept the idea to append {{Age in years and months}}.

To avoid a repetition of this discussion in some years when plants become non-operational for reasons we did not yet consider, I find myself in favor the approach of a catch-all value that applies when the others don't, as in a Conditional (computer programming). Either something like Out of service or alternatively Non-operational or Not operational, since there is an advantage to a value not starting with an already used letter. Regardless of what we decide on, I think we should also try to provide a description of each value, ideally linked when used in the infobox. If it is technically possible, I would prefer 'OS' for 'Out of Service', 'OP' for 'Operational' (keeping 'O' for backwards compatibility with a note in this documentation that 'OP' is preferred). Lklundin (talk) 14:19, 19 February 2017 (UTC)

Another, related topic is the subset of plants under construction with no activity for many years. For example, the Bellefonte Nuclear Generating Station had its construction suspended in 1988, and has as 'Status' the free text 'Suspended', to which I have appended the above 'for {{Age in years and months}}' which currently comes out to 'Suspended for 29 years, 1 month'. We could also provide a specific value, S(suspended), for this case, with the explanation that it applies to a not-yet commissioned plant. --— Preceding unsigned comment added by Lklundin (talk) 15:04, 22 February 2017 (UTC)

My brainstorming of options may have been confusing, so I would make clear my position: I don’t feel good about listing to many status values. My rule would be: a new option should be warranted only if at least 10% of world plants or reactors are involved (about 400 so say 40 units, less or more).

The values P, U, O, D are values that all plants go through.

Some plants would go out-of-service for any non-technical reason (economics, politics and so on) and that is the M value. That happens with all type of plants, and with many plants, including some few nuclear plants (the late have low operational costs, so economics would favor using them, albeit political pressures and taxing).

Quite a few plants go from the P to C status and so we have a value for cancelled projects.

A bunch of closed plants take many years before decommissioning is complete, so we added the B value.

Actually we have around 40 nuclear units under improvement (power up-rates, new security rulings – i.e. Japan – and so on), and I remember a bunch of conventional plants that have been upgraded, so it would be justifiable defining a specific value. One value, which could be one (one choice, please) of the following: I=Improving , U=Upgrading , R=Refurbishing/reconstructing/rebuilding (which ever). I would discard upgrading, because it uses already used U letter. Not that we need to stick to a one letter code, but I would prefer a one letter code: I and R are free.

Other cases (not above described) of not operational plants (out of service) are uncommon and I think that free text is more adequate. Out of service would make sense only if we wanted to bunch together mothballed and upgrading plants with the uncommon other cases. Fukushima Daini Nuclear Power Plant and Bellefonte Nuclear Generating Station are special cases. The later is actually a mix between a cancelled plant and a new proposal. --Robertiki (talk) 05:38, 26 February 2017 (UTC)

In the absence of consensus for clarifying the status of non-operational plants with a new value for 'Out of service' or analogous, I have started clarifying the status of such plants with the free text 'Out of service', optionally using the above-mentioned {{Age in years and months}}. Lklundin (talk) 11:49, 1 March 2017 (UTC)

I think that using 'Out of service' is a good solution in cases we can't add more specific reason (one could always spell the status out instead of using defined letter codes). I also don't see a problem with a potential overlapping and that defined statuses are not exclusive. Infoboxes should be as precise as possible but also as short as possible. The aim should be to use description which fits for the plant most precisely, but it should not be necessarily pre-defined or exclusive. Beagel (talk) 19:32, 1 March 2017 (UTC)

infobox coordinates

per Wikipedia:Coordinates in infoboxes, I have added support for |coordinates= and tracking to find uses of the old syntax. a bot will assist with converting to the new format, and there is no real urgency to do so since the infobox will support both formats until all have been changed. Frietjes (talk) 20:21, 16 January 2017 (UTC)

The old parameters:

| lat_d     = 11
| lat_m     = 12
| lat_s     = 13
| lat_NS    = P
| long_d    = 24
| long_m    = 25
| long_s    = 26
| long_EW   = L
| coordinates_type       = type:landmark
| coordinates_display    = inline,title

are changed to:

| coordinates            = {{coord|11|12|13|P|24|25|26|L|type:landmark|display=inline}} 

or alternate, straightforward format:

| coordinates            = {{coord|11.xxx|P|24.yyy|L|type:landmark|display=inline}}

I am suggesting putting in the docs the second format as sample.--Robertiki (talk) 03:52, 17 January 2017 (UTC)

@Robertiki: Is there any specific reason you prefer the second option? Beagel (talk) 19:21, 1 March 2017 (UTC)

Yes: instead of loading three values, I am done with only one copy/paste. And Google maps function "What's here?" returns the coordinates directly in decimal form. --Robertiki (talk) 19:46, 1 March 2017 (UTC)

Definition of generating unit

At Shidao Bay Nuclear Power Plant the chinese are building two HTR-PM reactors that together drive one steam turbine. The reactors are 250 MW_t each and the turbine drives a 200 Mwe generator. How many units are they ? One or two ? --Robertiki (talk) 21:39, 1 March 2017 (UTC)

Average generation

I have a few problems with the ps_annual_generation field. The label for this seems to be "Average generation". Clicking on the label takes us to Gross generation. That article was a bit of an unsourced mess but I fixed it.

First, shouldn't it say right in the label whether this is gross or net?

Second, nowhere does it say that this is annual output. Could be per day, per hour, over the total life of the plant. We don't know unless we look at the template doc or the infobox source (in which case we can infer it from the name of the field).

Third, "average" over what period of time? The specified year? That wouldn't make any sense. Over the lifetime of the plant? Kendall-K1 (talk) 20:22, 28 February 2017 (UTC)

@Beagel, Robertiki, and Rehman: I see this was discussed and changed last year. Changing "annual" to "average" was wrong; it's not always an average, since it could be for a single year, and even if it is an average, it's still energy generation per year. This should be changed back to "Annual generation". Kendall-K1 (talk) 02:02, 1 March 2017 (UTC)

In fact there was a gross error in the definition given. But the article in the past was good sourced, only the external links had gone dead. I have recovered the two most important ("Output Measurement - Net vs Gross" and "Measurement Of Net Versus Gross Power Generation For The Allocation OF NOx Emission Allowances").

First: I agree that right in the label it should be stated as generation. It happens often that editors get the net value.

Second: I don't agree about the time span doubt: "average" is used with a year span. Have you examples of a different use ?

Third: you are right. I remember to have read that the average is calculated over at least a 5 year span, but now I can't find where. We should agree on some rule and explain in the documentation.

Let us see how it works now. There are two parameters involved (with following description):

ps_annual_generation

Average annual gross power generation. For a single-year value, enter the year in the ps_annual_gen_year parameter. GW·h suffix will auto added for values without units.

ps_annual_gen_year

Year of the given annual generation data. Enter Planned if the given data is a planned estimate.

Example 1 - only ps_annual_generation given and ps_annual_gen_year parameter missing or blank. It defaults to average, as in Ikata Nuclear Power Plant (where I have calculated the value over a five year span). Output is:

Average generation 1,234 GW·h

Example 2 - ps_annual_gen_year has Planned as value. Sample in Solana Generating Station. Output is:

Planned generation 1,234 GW·h

Example 3 - ps_annual_gen_year has a number (year) as value. Sample in Genesis Solar Energy Project. Output is (with 2015 as year value):

2015 generation 1,234 GW·h

I suggest to change generation to gross output as in the sources that I recovered. Otherwise "gross generation" is too long. The three samples above would look like:

Average gross output 1,234 GW·h

Planned gross output 1,234 GW·h

2015 gross output 1,234 GW·h

Documentation should be changed (if we agree over the five year span) to:

Average annual gross power generation averaged over at least a five year span. For a single-year value, enter the year in the ps_annual_gen_year parameter. GW·h suffix will auto added for values without units.

--Robertiki (talk) 05:56, 1 March 2017 (UTC)

I agree that the span is intended to be one year. That's not the problem. The problem is that unless I am a power plant engineer, or I have read the template documentation, there is no way for me to know that. If I am told the plant has produced 1,234 GW·h over some period of time, but am not told the period of time, I might just as easily assume this plant has an output of 1,234 GW, and produced 1,234 GW·h over a period of one hour. Kendall-K1 (talk) 14:10, 1 March 2017 (UTC)

Perhaps a small note outside infobox that all figures are per year unless otherwise specified ? Infobox should be kept minimal. TGCP (talk) 15:09, 1 March 2017 (UTC)

@TGCP: I would agree fully with you but by my understanding this is the only field in this infobox which uses annual data. Maybe we should put a footnote just for this field? Beagel (talk) 19:20, 1 March 2017 (UTC)

For now I have activated direct access to infobox documentation and talk pages. I remember the first time I searched the documentation page without much knowledge of Wikipedia internal workings: it took me hours to find it. A simple link would have saved me the day. I suggest not to link the edit page. --Robertiki (talk) 20:02, 1 March 2017 (UTC)

How do we touch all pages to activate the new infobox ? With a bot ? --Robertiki (talk) 20:04, 1 March 2017 (UTC)

I still think we should just change "average" to "annual". If it's over a five year period, and it says "annual" then it's obviously an average. If it's over a one year period, then it's vacuous to say it's an average. Kendall-K1 (talk) 00:23, 2 March 2017 (UTC)

That would be to default to:

Annual gross output 1,234 GW·h

I could live with that. Should we go ? --Robertiki (talk) 05:31, 2 March 2017 (UTC)

Sounds good to me. Lklundin (talk) 12:15, 2 March 2017 (UTC)

I made the change. I used {{nowrap}} instead of (&)nbsp; because I have read that NBSP is deprecated. Indeed just writing NBSP is tricky (you se nothing), and I had to put those brackets to spoof the ampersand. But in a template use of nowrap is not easy. --Robertiki (talk) 00:15, 3 March 2017 (UTC)

Having now seen it in practice, I think we need to make a small adjustment. As Robertiki carefully explained above, when 'ps_annual_gen_year' has the value 'Planned', the generated text is 'Planned gross output', but seeing it in practice I really think it needs to be 'Planned annual gross output' (or something else with 'annual'). Otherwise there is no indication of the time frame of the production and a reader would be justified in assuming it was the planned production for the projected lifetime of the plant. Something similar can be said of the 'Average gross output'. Lklundin (talk) 14:01, 5 March 2017 (UTC)

Infobox power station is a table, i.e. names should be ‘’precise’’ but not ‘’detailed’’. The place for the details is the article body. As already discussed a couple of weeks ago. I don’t see how a reader could assume that the planned production is for a projected lifetime of the plant. There is nothing as a projected lifetime in the infobox to link to such an assumption. Have you examples of a different use of Planned gross ouput (i.e. not as a yearly generation) ? Third, if reading the article body does not clarify, in doubt, today, the documentation is only one click away. --Robertiki (talk) 16:42, 5 March 2017 (UTC)

Gross ouput or net output ?

I made some math here and have now realized that all nuclear production data from PRIS is net output and not gross output. So what do we do ? Have we a source of nuclear plants gross output ? Or should we change the name to net output ? --Robertiki (talk) 15:58, 7 March 2017 (UTC)
I feel that that does not touch the Capacity, which may stay as gross (Nameplate, i.e. maximum effect). I would be inclined to change production data to what actually the plands sends out, i.e. net output. On one side, we describe what is the maximum potential of the unit (Gross capacity), on the other side, we supply what is the useful output (Net output). For me, it looks fine. --Robertiki (talk) 16:06, 7 March 2017 (UTC)
Also EIA returns the generation data as net output, as per EIA. Compare 2015, the same as per PRIS. --Robertiki (talk) 05:02, 8 March 2017 (UTC)

Proposal to change name of ps_annual_gen_year to ps_annual_gen_desc and adding following description:

Parameter	Description
ps_annual_generation	Annual power generation averaged over at least a five year span. To be used in combination with the following ps_annual_gen_desc parameter. GW·h suffix will auto added for number without unit or any other text.
ps_annual_gen_desc	Given generation value exact description. If no description is given, it will default to Annual (i.e. it will expand to Annual generation). Enter following text: Planned net if given data is a planned estimate of the net output Planned gross if given data is a planned estimate of the gross output YYYY net, if given data is year YYYY net output YYYY gross if given data is year YYYY gross output Annual net if given data is a average net output Annual gross if given data is a average gross output

Sample run of test cases in the sandbox. If the editor has not read the documentation, there is no knowledge of what type of value he as input, so a generic Annual generation looks to me as the more sensible choice. Proposal may be skipped if we agree only to net production, that looks to me a value more easily found in the leading sources. --Robertiki (talk) 11:57, 10 March 2017 (UTC)

Do we need the child embed ?

I am referring to the line:

| child = {{{child|{{{embed|}}}}}}

Long ago, it was necessary to use embedding in order to create infoboxes with more than 99 rows; but nowadays there's no limit to the number of rows that can be defined in a single instance of {{infobox}}. Is the code still needed ? --Robertiki (talk) 13:13, 10 March 2017 (UTC)

Easy access to infobox documentation

@Rehman: Referring to your edit, there is the problem of giving easy access to the editors to the documentation. Instead in your summary you state: "lets not have a direct link to the template from every single article please". Why not ? --Robertiki (talk) 17:25, 5 March 2017 (UTC)

Sorry for the rude-sounding summary, it was not meant as such. I had just come online after a long day. Compared to the total number of visitors that can see the template/articles, only a very tiny fraction of them are actually editors. Adding direct links to internal aspects of the project (i.e. template documentation) is simply clutter IMHO, and is against the purpose of an infobox (i.e. providing critical information in a simple/summarized format). Of course, if there is evidence that this is a common practice, the links could be added back with concensus from our community. For the record though, I am leaning towards not adding them. Kind regards, Rehman 14:15, 6 March 2017 (UTC)

The link is small, and the editors need it, otherwise we have editors using the net capacity values, putting the thermal capacity as heating capacity, and so on. Look here; you have a direct link also to edit the template. Instead I have only given a fast lane to view and to talk. If your afraid of editors "breaking" the template, there could be other solutions:

* - page is already semi-protected and could also be fully protected.

* - we could make a documentation page separated from the template (no links on this documentation page to the template)

* - we could put the link to the documentation page in the talk page box of each article which uses the template

* - we could change position, as here, where the templates have the small link on the right of the box name

I would appreciate any solution that helps the more willing editors to write correct information and find the place to talk on proposals or questions. --Robertiki (talk) 04:43, 7 March 2017 (UTC)

I just use the "Templates used in this preview" list at the bottom of the page while editing. All infoboxes have fields that are not self-documenting. I don't think this infobox is special enough that it requires a direct link. Kendall-K1 (talk) 11:18, 7 March 2017 (UTC)

I did not know of this possibility and I guess a lot of editors neither. And anyway, an editor that knows that, probabily knows also how to write template:infobox name in the search field. So what ? All infoboxes should have a direct link to the documentation page or an alternative way to easy access the documentation. What we are loosing are field professionals, that sometimes peek on wikipedia and do not have the desire to deep in on Wikipedia complicated structure, unless they are in computing. We should let the doors open. --Robertiki (talk) 12:31, 7 March 2017 (UTC)

That should probably be discussed at Template talk:Infobox. Kendall-K1 (talk) 13:14, 7 March 2017 (UTC)

Actually I've changed my mind. Many infoboxes, including the top level Template:Infobox, have a little V-T-E in the bottom right corner. I have no objection to including that in this infobox. Kendall-K1 (talk) 13:21, 7 March 2017 (UTC)

You have put me on the right track. It looks that inserting

| name = {{{name|<includeonly>{{PAGENAMEBASE}}</includeonly>}}}

enables V-T-E per default. --Robertiki (talk) 13:21, 10 March 2017 (UTC)

Documentation of optional control parameters. --Robertiki (talk) 14:02, 10 March 2017 (UTC)

References in infobox

If agreed, I would add the following section in the documentation:

== References ==
If the material in the infobox requires a reference (see WP:MINREF for guidelines) editors should first consider including the fact in the body of the article. Only if the article is in the stub stage references may be needed in the infobox. References put after numbers block autosuffix (i.e. units) to be generated in the infobox.

as per following WP:INFOBOXREF. --Robertiki (talk) 14:50, 10 March 2017 (UTC)

Thermal power/capacity/efficiency

Specific to thermal power plants we have a field 'ps_thermal_capacity' defined simply as 'Thermal capacity', linking to MWt, a redirect to Watt#Conventions_in_the_electric_power_industry, which explains that MWt is the "thermal power produced by the plant". Now, our page Thermal power station explains that any thermal power (i.e. heat) produced by the plant but not utilized as electricity (or in cogeneration) is an undesired bi-product, waste heat which "must leave the plant in the form of heat to the environment". At least some jurisdictions constraint the forms of this waste heat disposal to limit any thermal pollution. As such the thermal power is not merely an asset or capacity but also in some sense a liability of the plant. This is especially true for the subset of thermal power stations that are nuclear where significant effort goes toward ensuring an uninterruptible removal of the decay heat (which is typically massive, given the typical nuclear power plant's massive nameplate capacity) that persists for days or weeks also after a (temporary) reactor shut down to the point that it has the potential to damage the plant.

Secondly, in the infobox of some power stations (e.g. Łagisza Power Station) the field is used to specify a useful heating power actually delivered in cogeneration, maybe in accordance with the implied meaning of the label, but hardly in accordance with its linked definition.

As such I find that the field 'ps_thermal_capacity' is ambiguous and I would like to suggest these changes related to thermal power stations:

• Introduce the field 'ps_thermal_power' labeled 'Thermal power' with default unit megawatt, the rationale being that the actual thermal power production is an essential characteristic, even if only partly delivered. This power would be limited by but not necessarily equal to the energy content of the consumed fuel per unit time.
• Introduce the field 'ps_thermal_efficiency' labeled Thermal efficiency and defined as the dimensionless ratio between the nameplate capacity and the above thermal power. This efficiency is a key number in thermal power plant design and management and can be compared between different plants and types of plants as well as to fundamental theoretical limits, such as the Carnot efficiency.
• Introduce the field 'ps_heating_power' labeled 'Heating power', for the delivered heating power and limited to cases of cogeneration, again with default unit megawatt. The rationale for putting 'heating' in the definition is to clearly distinguish it from the thermal power. With this name and definition this field would apply to any type of station with a cogeneration field set to 'yes', presently thermal, nuclear and geothermal.
• Temporarily document the field 'ps_thermal_capacity' as deprecated, referring instead to 'ps_thermal_power' and 'ps_heating_power' and perform a manual review of the about 50 articles that currently use this field (in more than one meaning), and then remove this field when the reviewing process is complete. (In case of a consensus I would volunteer to do this work, to improve the clarity of our power station articles).

A discussion of this intended improvement would be appreciated. Thanks. Lklundin (talk) 13:27, 4 March 2017 (UTC)

@Lklundin: You are correct that the current link makes 'ps_thermal_capacity' ambiguous and it should be changed. That field was introduced specifically for co-generation plants such as Łagisza Power Station which in addition to electric power generates useful heat for the industrial use or for the district heating. I support replacing 'ps_thermal_capacity' with something more precise (your proposed 'ps_heating_power' is an option) which would be only about the capacity of generation of useful heat (used for co-generation plants and heat plants only). In general, if everybody agrees that this field should be used for the useful heating power only, please go forward checking and changing these fields. As for introducing 'ps_thermal_efficiency', I somehow reluctant about introducing new fields, but you are right, it is an important figure (although quite often it is hard to find this figure about the certain plant). Beagel (talk) 14:17, 4 March 2017 (UTC)

I would be opposed to inventing our own definition of thermal efficiency. If we include this figure, I would want to know it's calculated in a way that is used by the power industry, and is calculated in the same way for every article. Kendall-K1 (talk) 16:19, 4 March 2017 (UTC)

OK, to keep things simple I suggest to defer the introduction of a thermal efficiency to a later and separate discussion, since it does not have any bearing on the remaining, proposed change. Lklundin (talk) 17:36, 4 March 2017 (UTC)

I would add that to not flood the table with new parameters, I would avoid the inclusion of entries you can simply get recalculating other entries in the table. --Robertiki (talk) 16:58, 5 March 2017 (UTC)

I am in favor of the rest of the proposal, for the reasons stated. Kendall-K1 (talk) 17:01, 5 March 2017 (UTC)

Thanks to all for the provided feedback. @Robertiki: I was going to align the sandbox to the current, actual infobox to try out the proposed changes, but then I noticed that you already made some contributions to the sandbox related to the proposal. Is it OK if I reset the sandbox, or would you prefer to go ahead and implement (some of) these changes? If so, then feel free to let me know that you are going ahead with this. Lklundin (talk) 19:59, 5 March 2017 (UTC)

I was looking at the Cogeneration article (a mess that has distracted me, found confusion about combined cycles ad trigeneration and so on) to find inspiration for a more precise definition as heating power. Instead of a new thermal power, I would prefer to keep thermal capacity, which is well paired with electrical capacity, obviously with updated description. That would also spare some work and make it easy for the editors that work by memory (there is a general economy in avoiding purely cosmetic changes). After some thoughts, and remembering that power in american english is not what we are used as translated from other languages, in conclusion, I agree that ps_thermal_capacity, as used, was ambiguous, but because it is usually used in defining the thermal power (as in physics), as per here, I would not change its name, but only update the description. And reading EIA, that the new parameter you suggested would be better with a name like ps_heating_capacity, labeled CHP heating capacity, precise without being long. You may see a test sample in the sandbox. In other words the proposal is simply to add the new parameter ps_heating_capacity. --Robertiki (talk) 02:00, 6 March 2017 (UTC)

@Robertiki: With the above information from Beagel that 'ps_thermal_capacity' was introduced specifically for useful heat delivered by cogeneration plants it seems a less than optimal solution to keep this demonstrably confusing field with a new definition different from the original one. Given the consensus prior to your counter-proposal, could I ask you to please feel free to ask for any clarification you may need and to maybe reconsider your position? Thanks. Lklundin (talk) 11:34, 6 March 2017 (UTC)

Incorrect. It was born here and from the start there was never a reference to cogeneration. But in the documentation, fromt the start, you find only the wiki-link to thermal capacity, as it should be. So, the usage made in Łagisza Power Station is utterly wrong (and from that follows your wrong assumption) and is simply a consequence of the editors not having easy access to the documentation (see talk). I have given a source (no WP:NOR, please) that supports "thermal capacity". I will suggest you reflect on this point: in your native language, would you write Power Plant ? I suspect that your disregard of using capacity above power stems from your native language. Beside, I understand, as I had the same problem. I would suggest, when you translate your thoughts, not to translate the single words, but make an "image" in your mind, and search the definition that fits that image in a english dictionary or in a wikipedia article. In english power means also mechanical energy, so it is a ambiguous word. In Science, power is regularly used as a concept of energy over time, but in the industrial world you find wording as power capacity, where it is clear that power means something different as in other languages (as translated). Look here: in most language you would write (translated): "turbine power", but instead you find "turbine capacity". A consequence of searching precise wording on the face of a double meaning of the word power. So you find generating capacity and not generating power as it would be in other languages (translated), and so on. You was right starting this talk, but the problem is simply the missing "heat" parameter. What is your position on CHP heating capacity ? --Robertiki (talk) 04:01, 7 March 2017 (UTC)

@Robertiki: What you exactly mean by It was born here? From this diff I can't find anything about the thermal capacity. And by my understanding (maybe I am wrong), that edit was somehow related to the UK specific power station infobox template. By my memory the issue of the the field of thermal capacity for the thermal power plants was raised in the connection of introducing the cogeneration field sometimes in 2010 when this template was totally rewritten by Rehman. Maybe Rehman, TGCP, NortyNort and others who were around that time can remember it better. Beagel (talk) 18:25, 7 March 2017 (UTC)

This mundane question is something I can try to answer (in logarithmic time). The documentation of the field 'ps_thermal_capacity' was introduced by user Rehman here, where it replaced an earlier field 'thermal_power_all', documented as 'MWt capacity' also by Rehman starting from here. Lklundin (talk) 19:49, 7 March 2017 (UTC)

Speaking for myself, I would like to add that my main goal with this discussion is to avoid the current discrepancy in the use of the 'ps_thermal_capacity' across different pages, whereas the actual field name is less important given that we can improve on the documentation. And Robertiki does have a point that the International Atomic Energy Agency uses 'Thermal Capacity' (e.g. in their Power Reactor Information System) in the meaning of the thermal power generated by the unit, rather than as useful heat delivered in cogeneration. For any useful heat delivered by the plant I think a label with 'heating' in it would be helpful. Putting 'chp' in the label seems more like an alternative to 'cogeneration' so I think the infobox should avoid using both.

If we end up with a field specifically for useful heat delivered, is it possible to make the (preview of the) template produce a warning, if this field is used without a cogeneration field set to 'yes'? This would help to avoid incorrect usage.

PS. to Robertiki: I think your technical arguments are convincing enough and while I believe you are just trying to help, I also think that your arguments are actually weakened when you try to build further reasoning on what is really just your own speculation on how another editor's contributions may be influenced by their native language background. Lklundin (talk) 20:39, 7 March 2017 (UTC)

@Lklundin: I think that the linkage between this field and co-generation field, what you suggested, is useful. The minor problem is that the same infobox is used also for few heat only plants (e.g. Kawęczyn Heat Plant) which technically are not co-generation plants but could be converted easily by adding a turbine. I don't think we should create a separate infobox for these few heat plants which have their own article. Beagel (talk) 07:03, 8 March 2017 (UTC)

Beagel you are right, I have been tricked by the transcluded documentation. Lklundin, you have pointed to the correct date/event. And now I remember the talks, starting from the first one. At first, talking about cogeneration, one may think that all the unused thermal power is deliberable for heating. But you were correct, the heating capacity is another (lower value) data.

PS: and sorry for my confused speculation, but I strongly believe own language background influences the linguistic choices, unintended offense, if that has happened. --Robertiki (talk) 04:42, 8 March 2017 (UTC)

Notwithstanding how we will name this field, if we agree that it should be used for useful heat only (for co-generation planst and heat only plants), the documentation should be corrected and updated with an explanation as soon as possible. Beagel (talk) 07:03, 8 March 2017 (UTC)

I will try to summarize:

I believe we still have consensus for two fields, one for thermal power (that IAEA calls thermal capacity), and one for delivered heating power in cogeneration.

Three options seem possible:

A) Replace 'ps_thermal_capacity' with two new fields (e.g. 'ps_thermal_power' and 'ps_heating_power') i.e. my original proposal, or

B) Keep 'ps_thermal_capacity' in the meaning of thermal power (that IAEA calls thermal capacity) and introduce a new field for delivered heating power in cogeneration (e.g. 'ps_heating_capacity') i.e. the proposal by Robertiki, or logically

C) Keep 'ps_thermal_capacity' in the meaning of delivered heating power in cogeneration and introduce a new field for thermal power (that IAEA calls thermal capacity), for which I think we have no suggested label.

Regardless of the option and labels that we choose there seems to be consensus that we need to improve on the documentation, sooner rather than later.

Additionally, there seems to be support for the idea that a field for delivered heating power should be implemented as requiring a cogeneration field set to 'yes'. In that connection it was pointed out that while our infobox is designed specifically for power stations that deliver electricity, it can be (and is) conveniently used for thermal plants that only deliver heating. In order to keep the requirement that a cogeneration field is set to 'yes', we could continue to support this special case by specifying that a non-electricity producing thermal plant specifies its heat production via the thermal power field. That would make sense since basically all produced heat is delivered, without cogeneration.

With the various new information and opinions, I am personally starting to think that while all three options are acceptable (with proper documentation), option B) is the best, with option A) as second best.

Did I miss something?

What do others think?

Thanks for all the input. Lklundin (talk) 13:06, 8 March 2017 (UTC)

Attempting documentation as following:

Parameter	Description
ps_thermal_capacity	The thermal power generated by the primary source in a thermodynamic cycle type plant. MWt suffix will auto add if number is not followed by any text (i.e. unit, link or text).
ps_heating_capacity	The thermodynamic cycle discarded thermal capacity share recovered in cogenerating plants for heating. MWt suffix will auto add if number is not followed by any text (i.e. unit, link or text).

Any suggestion welcome. --Robertiki (talk) 13:48, 10 March 2017 (UTC)

I support your proposal of a new label (per the above B) and based on the other (non-)comments, I take that as consensus.

Thanks for the documentation suggestions.

I think a link to Thermal power station would be natural. The MWt not so much. It conflates a physical quantity and its physical unit, a confusing practice which is specifically non-SI. Some SI-countries use for delivered heating instead the equivalent, standard unit MJ/s, but I think megawatt is preferable in the infobox. Also, since the fields are already labeled 'thermal' and 'heating' the addition of thermal to the unit is redundant in that context. As such I would, like for the nameplate capacity keep the default unit as megawatt. Otherwise the important thermal efficiency gets a unit like MW/MWt or MWe/MWt, rather than being dimensionless. Since almost all countries in the world are metric (and even more so in the fields of science and technology) I think the infobox should refrain from promoting a non-SI convention. Lastly, if a power station is deemed to have a strong tie to a unit convention other than the megawatt then it can use that convention in its infobox.

There are a few links that I consider important in this context, here is a suggestion that includes them (assuming that electricity is linked in a more prominent place):

Parameter	Description
ps_thermal_capacity	The heat energy per unit time generated by a thermal power station primarily for the purpose of converting it to electricity. This generated thermal power is different from the energy per unit time that the station may consume as supplied fuel. Similar to the station's nameplate capacity a purely numerical entry will automatically be multiplied by the unit symbol MW.
ps_heating_capacity	Any heat remaining after electricity production that the plant delivers as useful heat in cogeneration thus reducing waste heat. Similar to the station's nameplate capacity a purely numerical entry will automatically be multiplied by the unit symbol MW.

Lklundin (talk) 10:22, 11 March 2017 (UTC)

The description should not be detailed, i.e. wrote as a definition (not Wikipedia's job, WP:NOR), but only help the editor which value to choose from the sources. This generated thermal power is different from the energy per unit time that the station may consume as supplied fuel ? That a boiler has looses is already considered when a source states the thermal power. I am not sure to understand what you have written, but I feel it is not needed, making the description ... cumbersome ?

I have no problem to use MW instead of MWt, I am only adding that MW/MWt or MWe/MWt, are always dimensionless. I would go to the point of prohibiting the usage of kWh, MWh, GWh, that are the cause of so many mistakes, (energy units should be MJ, GJ, TJ, ...), but they are widely accepted, as on the same line, in the energy industry, MWe and MWt are widely accepted to immediately express the difference between the thermodynamic higher value of electricity versus the lower usefulness of a thermal form of energy. In the solar industry there is also a MWr (radiant), because capturing the thermal power of the sun has also great losses and so underlining that from 1 kWr of energy there is a long way to the kWe is deemed relevant (kWr --> kWt --> kWe). Anyway, I am fine with keeping MW, but would help the editor (that maybe is not an expert): Unit is MW but sometimes the sources give the value as MW_t which is the same as MW. MW suffix will auto add if number is not followed by any text (i.e. unit, link or text). (--> the description should explain the infobox workings). --Robertiki (talk) 12:38, 11 March 2017 (UTC)

@Robertiki: The sentence distinguishing the generated thermal power from the fuel consumption attempts to summarize this previous discussion, so it just attempts to avoid incorrect use of the field. But imagine that it is not there. Do you then think my "definition" which combines 'heat', 'thermal power station' and 'electricity' is less useful than your own? In fact, I find your above English rather broken, so instead of rushing to provide your opinion you could take an extra moment to phrase your response, especially parts that could potentially make it to an article. So let's maybe await some input from others, it would especially be good with input from other previous contributors to this infobox. Further, since you seem to have a genuine interest in physics I urge you to familiarize yourself with the SI-standard, which helps with the understanding of essential concepts, such as that behind this: "Units are never qualified by further information about the nature of the quantity; any extra information on the nature of the quantity should be attached to the quantity symbol and not to the unit symbol" SI, 8th ed. (section 5.3.2, p. 132). Thanks. Lklundin (talk) 14:14, 11 March 2017 (UTC)

Not only my english is broken, but I don't understand what you mean with: "But imagine that it is not there.".

I don't have any feelings about your definition, because simply we should not put definitions in the description of the parameters. I have given a "description", not a definition.

I know very well the SI-standard, but, as explained, like I had to accept (succumb ?) to the kWh (which a prefer to write kW⋅h, following the SI-booklet), working as an Engineer, had also to accept the international usage of MWe, MWt and so on (i.e. PRIS and others]). But, what is your point ? I said I gave in to the MW unit.

About adding mention of the MWt, I wanted simply to help editors that may have doubts when they read, for example, 1234 MWt, and assure them that they have the correct parameter.

--Robertiki (talk) 15:06, 11 March 2017 (UTC)

As a mathematician I could wish I had the time to learn how you would define (or describe) the difference between a description and a definition and how you can classify the two above wikitables as each belonging to their own of these two categories. Maybe some other time. In the meantime I honestly can't see how my connection of 'heat energy', 'thermal power station' and 'electricity' can have even a touch of originality in the given context.

The SI-system recognizes that some non-SI units are so deeply embedded in our culture that their continued use is acceptable, for example the hour. As such the Euro NCAP can continue to define a speed as 64 km/h (18 m/s) and the electricity industry use kWh, also in metric countries.

Maybe some else wants to voice an opinion, before we go on? Lklundin (talk) 10:52, 12 March 2017 (UTC)

I find the proposed wording too academic, i.e. language used in classroom lessons, books, tests which require fluency from the reader. In other words, that wording is selective, some how excluding layman (and foreigners not so proficient in English) from joining. If it was in the article space, I would not object, but we are talking about the documentation pages for the editors, in which the language should be as in every day language (plain) as feasible.
You mistake me, the problem is not the hour unit itself, but that there is already a widespread SI unit for energy (joule) and no reason to use the kWh outside the technical world, because to the layman it is extremely harmful. There is no widespread unit for speed (apart c ?). How many times have you read, from tabloids to MPs parliamentary questions, that the speed of a car is given in gallons of fuel or that the fuel consumption is given in mph ? Instead I could list pages and pages of references swapping kW and kWh as if they were interchangeable. And don't you cringe at "kilowatt hour per hour" ? And more over, kWh is deprecated in the same booklet you suggested to read. Also IEEE and ASTM agree that kW h or better kW·h is the correct writing. The importance of the · or halfspace is that it helps to distinguish from the kW, hopefully giving some food for thought. Instead with the MJ, all would be simpler.
NIST states “... this Guide takes the position that a half-high dot or a space should always be used to avoid possible confusion;”. And BIPM states “In forming products and quotients of unit symbols the normal rules of algebraic multiplication or division apply. Multiplication must be indicated by a space or a half-high (centered) dot (⋅), since otherwise some prefixes could be misinterpreted as a unit symbol.”
Why the SI-system does not recognize that the pound and foot are units so deeply embedded in our culture ? Because attention to what is deeply embedded nullifies the purpose of an international common system of units. So there are no excuses insisting on using the kWh. Anyway, Wikipedia obviously reflects society and the sources, and so I must use the kWh (defaulting to kW·h), although my dislike. Example: so many people are overzealous supporter of wind and photovoltaics as conflicting with nuclear (which they are is not) and that stems from the confusion between kW and kWh. And so the Germans are oblivious that if it were not for the heavy cut in consumption, the would have busted the CO2 emission limits.
On the other side, MWt does no harm, and after perusing Wikipedia and a bunch of old discussions, I am returning to MWt as autosuffixed unit. The reason ? It is in the most notable sources EIA and PRIS. Like it or not like it, that is the society. Attempting compromise, phrasing in your points:

Parameter	Description
ps_thermal_capacity	The thermal power input in the thermodynamic cycle conversion of the plant. MWt suffix will auto add if number is not followed by any text (i.e. unit, link or text).
ps_heating_capacity	Any heat remaining after electricity production that the plant delivers as useful heat in cogeneration thus reducing waste heat.MWt suffix will auto add if number is not followed by any text (i.e. unit, link or text).

--Robertiki (talk) 04:43, 13 March 2017 (UTC)

Thank you for that. Since the thermal capacity field is specific to a thermal power plant I frankly find that link to be more to the point than the underlying and very generic thermodynamics, furthermore 'thermodynamic cycle' does not have to involve production of electricity so I find the most recently proposed definition less than optimal. Simplifying my own suggestion to "The heat generated by a thermal power station primarily for the purpose of converting it to electricity", seems more to the point and sufficiently accurate. If you deem it useful to link to MWt, then that would seem more natural where it is directly mentioned, in the description of the default, (now mixed-up) physical quantity/unit. Since by now I have stated my opinion at length and in the absence of feed-back from others, I think you should go ahead and make the change that you feel is the best. Lklundin (talk) 10:23, 16 March 2017 (UTC)

What about the solar thermal plant and geothermal plant? Beagel (talk) 10:12, 17 March 2017 (UTC)

From a technical point of view, the new field labels are prefixed with 'ps_' and thus belong to the generic power station namespace and are as such not precluded from use in any instance of the template. From an engineering point of view, the thermal power station does not care how its thermal power is generated, it just converts it to electricity. As such a nuclear, a geothermal and a solar thermal (e.g. concentrator) station all belong to the set of thermal power stations. Lklundin (talk) 18:50, 17 March 2017 (UTC)

@Kendall-K1 and Beagel: At an early stage you expressed support for what I named A) above. Later Robertiki proposed what I named B) above and I accepted that proposal as equally good. In order to resolve the current, inconsistent use of 'ps_thermal_capacity' it would be good if we could finalize this. If any of you could comment in favour of Robertiki's proposed fields, then I would say that we have sufficient support to introduce them. Since there seems to be no consensus for a default physical unit for these fields I would say that given consensus on the fields themselves, we can go ahead and introduce them without a default unit, like most other fields in the template. Since their documentation is a separate matter, we can hash that out later. Given the above discussion I am proposing a concise description of 'ps_thermal_capacity' (basically the 1st sentence from thermal power station), thus seeking your support for:

Parameter	Description
ps_thermal_capacity	The heat generated by a thermal power station for conversion to electric power.
ps_heating_capacity	Any heat remaining after electricity production that the plant delivers as useful heat in cogeneration thus reducing waste heat.

- with the description subject to ongoing improvement, as for any other template field.

Lklundin (talk) 20:24, 20 March 2017 (UTC)

I can drop the autosuffixing and the explicit MW_t mention, but there being a consistent specific article about the field, a prefer to link that and not e generic "heat" reference. About my formulation as "input" heat, I am thinking of plants like Martin Next Generation Solar Energy Center. So I am converging to:

Parameter	Description
ps_thermal_capacity	The thermal power input in the thermal power station for conversion to electric power.
ps_heating_capacity	Any heat remaining after electricity production that the plant delivers as useful heat in cogeneration thus reducing waste heat.

--Robertiki (talk) 03:16, 23 March 2017 (UTC)

Idled and improving reactors

(restarting more specific case)
Following this source, Japan has more than forty reactors Idled. Not Out of service, but idled. Almost half have applied to NRA for safety improvements and safety assessments inspections to restart and other are following suit. They are not mothballed, but undergoing works to improve safety and busy preparing for NRA inspection. I feel heartened to settle with the value Status = I that would expand to:

Status      Idled or Improving

or

Status      Idled/Improving

and could also be applied for any other lengthy upgrading works. --Robertiki (talk) 06:32, 2 March 2017 (UTC)

We discussed this about a year ago but didn't consider the case where the reactor is not running now but will or might be later. This does seem distinct from "Closed" which we decided meant not running but not (yet) in the process of being decommissioned. It's a bit tricky because deciding between "closed" and "idled" requires predicting the future, but it does seem to me we do need "Idled". "Closed" just sounds too final.

Previous discussion: Template_talk:Infobox_power_station/Archive_3#Problem_with_.22decommissioned.22 Kendall-K1 (talk) 13:24, 2 March 2017 (UTC)

@Robertiki:, @Kendall-K1: Describing a power plant as 'Idled' has a clear connotation of an idle (engine), i.e. a machine that is operating continuously and has just momentarily gone from delivering useful work to not doing so (while its internal, moving parts are still being kept in motion via continued fuel consumption). In the above case, where plants have been in shut down for years, 'Idled' really gives an incorrect impression of the state. If the restart of a plant is pending a safety inspection as mentioned above, then 'Awaiting restart' seems to be a more accurate description of the plant, if we need to be more detailed than 'Offline' or just 'Out of service'. Further, since this seems to be a rather narrow status category, we do not need to describe this state with a word or phrase beginning with a letter not already used for the other pre-defined, broader categories. And, yes, I am aware that the Japanese plant operators wouldn't mind giving the impression that they have just temporarily idled their plants, but that grammatically correct use if the word 'idled' is not WP:NPOV. So let us we please avoid 'Idle(d)'. Lastly, from a grammar point of view 'Improving' is just terrible in comparison with our existing choices. Lklundin (talk) 12:08, 18 March 2017 (UTC)

What about Furbishing or Renovating ? --Robertiki (talk) 04:11, 23 March 2017 (UTC)

I have made an example with Embalse Nuclear Power Station. The reactor is under a 22 month long renovation, which will upgrade its capacity from 648 MW to 683 MW. I put a deletion line over the operational value 648, reinserted the UC paramater for the new value 683 and a status of R. The combination of UC and R should imply that there is no new reactor under construction, but a reconstruction of the same. Once operational, the deleted number would be upgraded and the UC parameter line deleted. Could be a solution ? --Robertiki (talk) 14:37, 24 March 2017 (UTC)

Klaipėda Geothermal Demonstration Plant

Klaipėda Geothermal Demonstration Plant is not a power plant. But infobox may be used for simple heating geothermal plants if we add a geo_thermal_capacity geo_heating_capacity parameter. The problem with using ps_thermal_capacity or ps_heating_capacity parameter, when there is no electrical generation, is that we have a Power generation header out of context. --Robertiki (talk) 17:10, 24 March 2017 (UTC)

And the caption reads "CHP heating capacity", which is not correct, as in Gdańsk Power Station. I am confused what to do. Any suggestions ? --Robertiki (talk) 11:05, 25 March 2017 (UTC)

Experiment done with Będzin Power Station, where I used ps_thermal_capacity for the direct heating from boilers and ps_heating_capacity for heat from the 13UCK 80 turbogas set. --Robertiki (talk) 12:18, 25 March 2017 (UTC)

Same reasoning for only heating thermal plants, as Kawęczyn Heat Plant. If we add a th_heating_capacity paramater, infobox power station could be also used for them. --Robertiki (talk) 19:26, 24 March 2017 (UTC)

More: I found a bunch of plants signed as cogeneration but I doubt they are strictly cogenerating plants. In cogeneration the heat is spilled from the steam turbine or the condenser. But in plants like Ahtme Power Plant we have a number of large boilers and only two small turbines (10 MW a 20 MW): it is impossibile to have 370 MWt of thermal output in cogeneration unless the turbines are working at a really awfully low efficiency (happens only with ORC cycles using low temperature heat). So I suspect that most of the heat comes directly from the boilers. It could be also that the small steam turbines are not in cogeneration. --Robertiki (talk) 10:57, 25 March 2017 (UTC)

More: What to do with heat pump technology as in Drammen Heat Pump ? Should we expand the infobox ? --Robertiki (talk) 12:25, 25 March 2017 (UTC)

Nuclear plants article names all caps or lower case

@Rehman: Looks like most nuclear plants have upper case for the trailing part of the name (Power Station) as in Beloyarsk Nuclear Power Station. But Wikipedia rules for article names states that "Use sentence case: Titles are written in sentence case. The initial letter of a title is usually capitalized by default; otherwise, words are not capitalized unless they would be so in running text.", which recently I copied in "about article title guidelines". Most UK nuclear plants follow suit, as in Heysham nuclear power station. I have some new articles to name, but before starting I have noted that, for example, Moorside Nuclear Power Station was changed to "all caps" "capitalized" one year ago, by one of us (Rehman), so before creating the new names, I would like an agreement about the issue. I don't think that we should start to change all names to follow the rule (it would be a really to much big undertaking), but any time there is an opportunity, like new articles or adjustments to current names (as changing from "project" to "station"), it would be sensible to follow the rules. A "List of nuclear power stations". Some problem applies for other technologies, as in "List of coal power stations". --Robertiki (talk) 02:42, 15 April 2017 (UTC)

If the long version is the official name of the plant, it's a proper noun and should be all caps. Determining the official name might be difficult, as I expect sources will differ. Kendall-K1 (talk) 12:03, 15 April 2017 (UTC)

Hey Robertiki. I share the same view as Kendall-K1 above. Rehman 12:11, 15 April 2017 (UTC)

Sorry, capitalized, not all caps. I assume that's what you meant? Power plant titles should never be all caps. Kendall-K1 (talk) 12:18, 15 April 2017 (UTC)

I have given some samples; to be clear: the difference is in the trailing description, i.e. "... Nuclear Power Station" or "... nuclear power station". My first thought was like yours, but after searching the rules (which I searched to explain to editors that would "decapitalize" not do it), and some volunteering at Wikipedia:Requested moves, I have understood that I was wrong. The point is: "words are not capitalized unless they would be so in running text". --Robertiki (talk) 20:53, 15 April 2017 (UTC)

Here are a couple of the discussion I have lurked: Talk:Penistone Line#Requested move 16 April 2017 and Wikipedia_talk:WikiProject UK Railways/Archive_37#Recent article moves removing capitalisation of .27line.27. Or Talk:Local nature reserve, Talk:None but the Brave, Wikipedia talk:Somebody else's problem, but also when to take exception Talk:People Like Us (film). That is how I changed my mind.

Per WP:TITLEFORMAT and WP:NCCAPS and MOS:CAPS, avoid unnecessary caps. What seem's to me is that here and there there is some consensus that want to take exception. There may be cases that warrant the exceptions, but I feel that they should be ... exceptions, because every exception may start a conflict. Is there any reason to keep “power station” (or “project”, etc.) capitalized ? I feel we should choose a consensus that doesn't conflict with the general rules to spare time about discussion every time a new editor applies the rules given above. Surely, there would also be new editors that don't know and don't follow the rules as per consensus. But the discussion in the latter case would be brief, with wikilinks to the general rules and the consensus. Instead taking exceptions requires to double explain why we ... take exception. --Robertiki (talk) 02:40, 17 April 2017 (UTC)

In addition to WP:TITLEFORMAT and WP:NCCAPS and MOS:CAPS there is also MOS:PN. Beagel (talk) 20:47, 18 April 2017 (UTC)

It's not hard and doesn't require any exceptions. If "power station" is part of the name, it's a proper noun and is written in initial caps. Otherwise it's not. For the examples given, it's clear from the sources and official web sites that the names of these plants are "Heysham 1" and "Moorside" (that last one even says "On 1 December 2011 NuGen announced that the name it had selected for its project was Moorside" right there on the web site). So the article titles should be "Heysham nuclear power station" (note we have a combined article for 1 and 2) and "Moorside nuclear power station". Kendall-K1 (talk) 03:25, 17 April 2017 (UTC)

"Referring to outside sources ?" I take one of the replies that made me change position: "... well you can find bad usage "outside" for anything you like, even by professional bodies that use caps as boosterism (against usage elsewhere)". And, are we being swayed by the appearance of items in titles that use title case? I would add: mostly the names that the english wikipedia uses are not original american or english names, but their translations from secondary sources. Translation should often involve changing cases, as in " Kraftwerke" (german) versus "centrali nucleari" (italian), but if the translator is, for example, a commercial of other nationality, he often goes following his native language rules when capitalizing. So I would weight carefully the secondary choices about names capitalisation.

Let us take a look at Quad Cities Nuclear Generating Station (where, beside, there is a discrepancy in the description Quad Cities Generating Station, with missing nuclear, but that is another question). The words are a mix of a given name and running text. I.e. Quad Cities should be capitalized because it is the given name of the plant. But what follows depends on the writer choice. The first and second source state "Quad-Cities Generating Station" (without "Nuclear") and "Quad-Cities nuclear plants" in the running text. The third, and owner source, states "Quad Cities nuclear plants" i.e. only as running text. Per owner, the plant name is "Quad Cities" with the added description as per writer choice. Fifth source, an official source, states only "Quad Cities" with appended running text. The sixth source, also owner's, states "Quad Cities Generating Station". Could we define the owner's choice as boosterism ? And our editor's choice of inserting "Nuclear" in the name, our consensus reached choice ? So, if we, as tertiary source, have added a Nuclear, why should we not have our rules for first letter uppercase ? The source never uses nuclear or station, but only Quad Cities, therefore it looks to me that generating station or nuclear plant is a description and not part of the plant name.

At the moment it looks there are two consensus, one, not written (have not found a discussion), about full capitalisation for most plants, and another, discussed ? (asking to @Yaris678:), for english plants (no capitalisation if not in running text). And that is confusing.

Once we have reached a first consensus here (which ever it is) I thought I could take the discussion, following that consensus, to Wikipedia:Requested moves about Quad Cities (for the nuclear discrepancy from the secondary sources), link to the present discussion for the uppercase part, to reach a larger consensus. --Robertiki (talk) 12:01, 17 April 2017 (UTC)

Hi All,

I can see this is tricky. First I will note that:

• I think you want the term title case not all caps.
• There is a strong preference on Wikipedia for sentence case.

This normally means that if something is the official name, it is a proper noun and capitalised. e.g. Faculties and departments of the University of Alberta is correct. "Faculties" starts with a capital, just because it is the first word. "University" has a capital because it is part of the name of institution... but "the" does not... even if the official name is "The University of Alberta". This is a well recognised exception.

The reason that this may be tricky, is that in some cases "Power Plant" may be part of the official name, and in other cases it may not... which would lead to an apparent inconsistency. Some people may be comfortable with that inconsistency... but then you will get companies themselves being inconsistent... and the independent sources too... at which point people may prefer to go for a naming convention.

I think I was asked cos I may know about stations in the UK.... I am afraid I still have to use Google. The first example I came across was this. Which looks like the official name is just "Heysham 2"... and similarly this, which suggests "Hartlepool" - the power station is sometimes added in lower case, sometimes not added at all, suggesting not in the official name.

To cap it all... we don't always go by official names.

So... I don't claim to have done a comprehensive survey... but to me it looks like it might be best to put terms like "power station" in lower case.

Yaris678 (talk) 12:47, 19 April 2017 (UTC)

Lua errors

I've just come across Changsheng Power Plant which has the errors "Lua error in Module:Wd at line 2053: attempt to index a nil value." in various fields in the infobox. I checked the parent cat, Category:Natural gas-fired power stations in Taiwan, and see that most of the others have infoboxes with the same error. Sun Ba Power Plant, has a different error, "Lua error: bad argument #1 to 'gsub' (string expected, got nil)". Just raising this in case there's a general issue that needs to be addressed. Nzd (talk) 23:16, 11 October 2017 (UTC)

Just to update, most of these errors have now gone (at least from that category). However Kuokuang Power Plant and Tatan Power Plant still show the same error (Lua error in Module:Wd at line 2053: attempt to index a nil value.) Nzd (talk) 17:59, 13 October 2017 (UTC)

You need to purge them. A side effect of the module or template being broken temporarily while and the page cacheing that version. Purging the page, by appending '?action=purge' to the URL (or you can enable it as a menu item) is the quickest fix. Another way is a null edit: open it to edit, hit save without making any changes. It will not be recorded in the history but counts as a null edit. If purging/a null edt does not fix it then there is an error, but I think in this case the error is already fixed.--JohnBlackburne^words_deeds 18:54, 13 October 2017 (UTC)

Yeah, that's done the trick. Thanks for the tip. Nzd (talk) 19:09, 13 October 2017 (UTC)

"Status" not conform to IAEA guidelines

There really should be no need to invent new status categories, and then miss on some that are used world-wide.

For Nuclear Power Plants, see https://www.iaea.org/PRIS/WorldStatistics/OperationalReactorsByCountry.aspx These status categories are missing: Long-Term Shutdown Permanent Shutdown

For Research Reactors, for which the template is also used, see https://nucleus.iaea.org/RRDB/ These status categories are missing: Temporary Shutdow Extended Shutdown Permanent Shutdown — Preceding unsigned comment added by Nunoni (talk • contribs) 19:15, 19 October 2017 (UTC)

Long-Term Shutdown and Permanent Shutdown (not under decommissioning) is covered with Mothballed. --Robertiki (talk) 05:58, 15 November 2017 (UTC)

Moving Pumped-Storage Power and Tidal Power sections to Infobox Dam

Pumped-storage power and Tidal Power have much more in common with Hydro Dam and on the other side Infobox power station template is growing to big, and is still not complete. Comments ? --Robertiki (talk) 04:43, 17 November 2017 (UTC)

I don't think tidal power has enough in common with infobox dam for a merge, however I am strongly in favor of merging pumped-storage into infobox dam as long as the relevant pumped-storage-specific fields in infobox power station are all properly and fully merged into infobox dam (ps_storage_hours, psps_generators, psps_pumpgenerators, psps_pumps, and the upper/lower reservoir info). I am especially concerned about retaining the upper and lower reservoir information for pumped storage — I'm not fully sure how exactly we'd merge this into the infobox dam template since we'd ideally want to expand the template to cover an upper reservoir+dam and a lower reservoir+dam, which is more than a bit complicated to do in practice given the way templates are structured, although I suppose it is doable, just time-intensive...

As far as migration goes, there's currently 116 articles using psps_generators, psps_pumpgenerators, and/or psps_pumps. That's quite a few articles to manually migrate...

Anyways, there's my 2 cents on the matter. Garzfoth (talk) 09:51, 18 November 2017 (UTC)

The current template used on Bath seems adequate to me. But if a change is needed, perhaps by including two infoboxes; one for upper+lower reservoirs, and one for generation/pumping? The Infobox power station need not include all kinds of power equipment. 116 articles is manageable, maybe a year's worth of trickle work. TGCP (talk) 17:35, 18 November 2017 (UTC)

I agree that the current template is adequate, although only minimally so. But if we're going to change to using infobox dam for pumped storage plants, then we should take advantage of infobox dam's numerous additional fields for pumped storage as well, which has upper and lower reservoirs/dams as opposed to just a single reservoir/dam (which is the way infobox dam currently works). Does that make sense? Maybe I need to mock this up. Garzfoth (talk) 21:43, 18 November 2017 (UTC)

I went ahead and edited infobox dam's sandbox to (somewhat crudely) integrate pumped storage in the way I was envisioning. You can see how it looks at Template:Infobox_dam/testcases#Most_params_.28new.29. What do you guys think of this? Garzfoth (talk) 22:30, 18 November 2017 (UTC)

I have made further refinements to the infobox dam sandbox template and have also created an example case of using the modified version of infobox dam with a pumped storage plant (Taum Sauk) to illustrate the real-world usage of the modified template (which can be viewed at Template:Infobox_dam/testcases#Example_for_Taum_Sauk. I think the sandbox template is mostly complete at this point and is ready to be merged into the main infobox dam template (which will require expanding the documentation a bit and updating the list of whitelisted parameters), but I don't want to move forwards with that until you guys weigh in on it. Garzfoth (talk) 01:11, 19 November 2017 (UTC)

Tidal power works like run-of-the-river hydroelectricity. And I would add that also the wind power section could be moved to the Dam infobox. Here the reason why wind is logically connected to hydro, but as no use with other power station infobox tech. --Robertiki (talk) 04:24, 20 November 2017 (UTC)

I added a figure here with a block overview of a generic power station that may explain some concepts about power generation. --Robertiki (talk) 04:52, 20 November 2017 (UTC)

If you want to merge in tidal power, I suppose it does makes sense to do so for tidal barrages, so I retract my opposition to that.

Wind turbines on the other hand have no relation to dams whatsoever that is relevant in this context. A pumped storage plant can be fed electricity generated from any source, and pumped storage plants were originally developed as a way to store surplus power from "baseload" coal and nuclear units at night for later use (using them to store surplus power from variable renewable sources is simply an evolution of their historical purpose), so there's no true associative argument to be made either.

While it is true that typical wind turbines and typical water turbines both harness mechanical energy to drive an electrical generator, the same is still ultimately true of steam/gas turbines - the prime mover is just a bit more complicated in those cases. Putting wind turbines in "infobox dam" would be wildly inappropriate unless we renamed it to something like "infobox dams and certain types of mechanical turbines". Keep in mind that infobox dam currently covers both power and non-power dams & reservoirs. It is logical to expand it to cover dams & reservoirs used for pumped storage or tidal barrages, but it is not logical for it to cover anything that doesn't involve a dam in some capacity (like tidal stream generators, wind turbines, solar panels, gas turbines, nuclear reactors, geothermal wells, combustion boilers, concentrated solar power, etc etc). Garzfoth (talk) 19:59, 20 November 2017 (UTC)

Wind turbines can provide an accessory service to a hydraulic system, also by mechanical means, not just electric. Think of the Dutch polder system. You have a bunch of windmills that, when there is wind, spin vertical shafts that, down in the basement, mechanically spin pumps, pumping water up to to a network of channels that flow to the ocean.

By increasing appropriately the number of these mechanical pumps, it could be possible to return water from this channel network (or a upper reservoir) through hydroelectric turbines that generate electricity, to certain polders for that purpose. That polder thus functions as a lower reservoir of a pumping system, where the wind turbines do not produce any electricity, but replace the function of drainage channels or tributaries to a hydroelectric basin. A solution like that, for example, could feed, say, a 100 MW hydro turbine, with a farm of wind mills having a simple pump each, and not a costly generator with gearbox each. That would be a tight connection between wind and a pumping station, not feasible with other power technologies.

I could, on the paper, envision the same solution with a wind turbine driving mechanically the feed pump of a steam turbine, but that would only be feasible if there were a constant wind, because the steam turbine would need the pumping continuously to work. So practically there is no way to use a wind turbine out of the above polder/hydro combination.--Robertiki (talk) 03:30, 1 December 2017 (UTC)

That's nice and all, but it has no relevance in the current modern world, and does not address the question of why electricity-producing wind turbines would be included in the infobox dam template. Nice red herring though. Garzfoth (talk) 06:46, 1 December 2017 (UTC)

Is this template broken?

Some of the pages I edit have a location map (example Hallett Power Station) and some don't (example Ladbroke Grove Power Station). As far as I can tell, the map and coordinate parameters are the same. Both are in Category:Articles using Wikidata location map with locally defined parameters but the broken one is also in category:Coordinates not on Wikidata and the working one is in Category:Coordinates on Wikidata.

There is nothing in the documentation of this infobox to suggest what I have done wrong, and no link at Wikidata:Wikidata:Coordinates tracking to give a hint on how to import the coordinates on to Wikidata if that is the underlying problem. Thanks for any help anyone can give. --Scott Davis ^Talk 12:49, 27 November 2017 (UTC)

After a few hours of digging into the guts of several templates and tinkering with stuff, I've managed to fix the problem. You may need to purge the cache before the location map shows up, but it works now. There may be an edge case remaining where this issue can still occur, but I'm not sure if it actually exists. If you see any more cases of articles using infobox power station not displaying the location maps please ping me so I can investigate further, otherwise I'm assuming the issue is fixed. Garzfoth (talk) 16:44, 27 November 2017 (UTC)

Came here after after noticing a large number of pages with errors at Category:Pages with script errors. Because of the way the category works this may not be complete, and they may not be all power stations but most are.

Looked at one and purged it but that did not help: it just made it display the error. --JohnBlackburne^words_deeds 19:35, 27 November 2017 (UTC)

Ah crap, it looks like that "edge case" isn't as much of an edge case as I thought it would be. I'll go try to fix the template. On the bright side I am pretty sure I know how to fix this since I already fixed a very similar error once. Thanks for pointing these out. Garzfoth (talk) 19:46, 27 November 2017 (UTC)

It's always fun when fixing one bug causes an even bigger one to appear. I think the issue is under control now, there's just a ton of pages that need their caches purged — I hope that eventually runs automatically, because I only manually purged a dozen or two pages to confirm that my solutions worked. The infobox power station template is now possibly a bit less "smart" due to the way I fixed the issue of it trying to insert the map template on pages with no coord+location_map data — it may or may not still pick up on Wikidata entries correctly when setting up that template, but even if it doesn't, it's no big loss at all. Garzfoth (talk) 20:26, 27 November 2017 (UTC)

@Garzfoth: As far as I can see, your edit here fixed the issue by adding another fallback option for the map. As a result, you can probably revert this edit. Thanks. Mike Peel (talk) 20:44, 27 November 2017 (UTC)

Thanks for pointing that out. I investigated that edit and discovered that it could be partially reverted, but the restoration of the ifeq param immediately caused issues so I was unable to fully revert my changes without re-breaking the template. The Wikidata entry detection stuff should be unaffected now (although the original logic may or may not even allow for proper detection direct from Wikidata like I thought it did, so it may not have even been an issue in the first place). Garzfoth (talk) 20:53, 27 November 2017 (UTC)

The problem is not with the coordinates. --Robertiki (talk) 03:30, 1 December 2017 (UTC)

What do you mean by that? Please be more specific. Garzfoth (talk) 08:07, 1 December 2017 (UTC)

You have to add a voice, for each article, in Wikimedia, complete with the property P625. Property P625 is the code for coordinate location. If you want, test with #if:{{#property:P625}} and on failure, select the old coding (to insert it, see the code at the moment of your edit adding cooling towers) as an alternate solution. The category:Coordinates not on Wikidata lists articles which have no P625 property. --Robertiki (talk) 04:47, 3 December 2017 (UTC)

My test case of Ladbroke Grove Power Station still shows coordinates not on wikidata, and still has no location map. Is there a one-click (or nearly as simple) way of "fixing" coordinates not on wikidata? The words "import it" on wikidata:Wikidata:Coordinates tracking are not a wikilink. If there was a simple process behind a link on those words, the backlog would grow much slower, and likely shrink. --Scott Davis ^Talk 12:10, 3 December 2017 (UTC)

@ScottDavis: There was a bug in how {{Wikidata location map}} handled locally-defined coordinates, which I've now fixed, and the location map shows up in Ladbroke Grove Power Station now. It's fairly easy to add values on Wikidata - click on 'Wikidata item' in the left-hand sidebar from the article, then 'add statement', type e.g. 'coordinates', copy-paste the coordinates into the box to the right, then click 'save'. Wikidata will sort out the formatting for you, or let you know if there's a problem. You also need to add 'country' for the location map to show up using only the Wikidata values. Thanks. Mike Peel (talk) 20:30, 3 December 2017 (UTC)

But, at this moment, the Sandstone Solar Energy Project article shows no 'Wikidata item', and so happens for all new articles. First you have to create the Wikidata entry for that article. --Robertiki (talk) 06:35, 5 December 2017 (UTC)

@Robertiki: I can't reproduce this. Trying your example at User:Mike Peel/Sandbox4 (where there is no attached Wikidata entry) doesn't throw an error. I also tried de-linking the Sandstone Solar Energy Project entry briefly, but couldn't get an error message there either. Thanks. Mike Peel (talk) 10:53, 5 December 2017 (UTC)

Sorry, I created Q44670891 after writing the message, just to verify. You memay test it with Itu nuclear power plant article. --Robertiki (talk) 13:56, 5 December 2017 (UTC)

@Robertiki: That one also looks fine? What am I missing? Thanks. Mike Peel (talk) 13:57, 5 December 2017 (UTC)

In the Itu article, after Page information the line Wikidata item is missing. Same was for the Sandstone article, before I had created Q44670891. --Robertiki (talk) 14:02, 5 December 2017 (UTC)

Aah, yes, that will be the case until the Wikidata entry is created! You can either do that manually (or link it to an existing one if the same topic exists in another language Wikipedia) if you want to start using the Wikidata functionality immediately, or a bot goes and creates new Wikidata entries for new articles every so often. The infobox should work as normal in the absence of a Wikidata entry, though, so the old-fashioned way of doing them still works. Thanks. Mike Peel (talk) 14:09, 5 December 2017 (UTC)

Wikidata support

Hello User:Robertiki. May I ask why you removed Wikidata support with this edit? Rehman 09:37, 5 December 2017 (UTC)

It was a fast test (undone in a couple of minutes), as explained in the undone description (... undo test). See above discussion, Template talk:Infobox power station#Is this template broken?, in which I stated that template was not broken, as explained. --Robertiki (talk) 13:56, 5 December 2017 (UTC)

Got it. Thanks! Rehman 08:08, 6 December 2017 (UTC)

I wonder if we should go the other way round and make this template Wikidata only. I would like to see a situation where the Infobox with no manual parameters would be suffice too generate the entire information. -- Magioladitis (talk) 23:44, 17 December 2017 (UTC)

Yes, that is the ultimate goal . :-) Rehman 01:14, 18 December 2017 (UTC)

Wind site elevation removal

I am proposing the removal of the wind_site_elevation parameter. What is his relevance ? I would instead put in a wind_total_height parameter, giving the maximal unit height from ground. --Robertiki (talk) 20:48, 17 December 2017 (UTC)

• Oppose. The tip height could be obtained by simply adding the hub height and blade length. Or depending on what you mean above, the total tip altitude could be obtained by site elevation + hub height + blade length. But site elevation is a unique parameter, and cannot be obtained through existing parameters. Hence I vote keep for that, and oppose adding new parameters based on the fact that we should keep the template short and concise. Rehman 01:20, 18 December 2017 (UTC)

I meant total "unit" height above ground, not the elevation, and no problem, I won't insist for the wind_total_height parameter. But what is the use of knowing the site elevation ? Or, on the other way, why not state it for all technologies ? I know that for wind it is important to know height above ground, but absolute elevation above sea level ? --Robertiki (talk) 06:54, 18 December 2017 (UTC)

Sorry for the late reply. Ground altitude is an important factor in wind farm development, as higher altitude mean steadier and stronger wind flow. It is also critical deciding factor for nearly all wind farms planned to be built on non-coastal/mountainous areas. The parameter got imported from {{Infobox wind farm}} in 2010. Cheers, Rehman 13:56, 1 January 2018 (UTC)

The importance of altitude depends on local conditions - mountains re-direct the wind around them, increasing the wind speed at their base. In some cases more so at the base than at the top (Canaries, Hawaii, Tehachapi/Altamont etc.; kind-of a sideways hill-effect). Mountain peaks and ridges benefit from being in more airflow less cluttered by other ground obstacles. Conversely, lower air density decreases power production. So altitude has influences which counteract eachother. The elevation parameter may not be relevant in many cases, but should only be removed if the infobox is big - and the body text should include elevation effects if notable. TGCP (talk) 17:01, 1 January 2018 (UTC)

Nameplate capacity gross power and net power

I want to underline that a nuclear reactor has no electric output, it is the same as a combustion boiler. It is the turbine-generator set that has a nameplate output (which is the gross output), which may be fully available to the step-up power transformers or not. It depends on the plant build and the season: so, stating the gross output says a lot about the plant potential and how difficult it is or not to up-rate the plant. The net output instead is a variable value, more of a statistical sort than technically fixed like the nameplate output. --Robertiki (talk) 04:52, 20 November 2017 (UTC)

I think you intended to respond to our talk page discussion with your second comment regarding gross/net output, but I'll reiterate - using gross capacity when net capacity is available is completely senseless, and net output capacity is a far more accurate and relevant figure, especially when you have generation and capacity factor right next to the figure (both of which relate directly to net output rather than gross output). Nameplate capacity can refer to either gross or net electrical output depending on the context, and in the context of a power plant, it is more accurate to use net electrical output (assuming it is available). You argue that gross electrical output is the most accurate and useful figure because the most fundamental components of a nuclear reactor or combustion boiler do not produce electrical power — in that case, you should have recognized that neither net nor gross electrical power output is related to a reactor or boiler's theoretical capacity for electrical power output, because reactors and boilers are fundamentally generators of heat energy first and foremost. Thus the rating of a reactor or boiler in MW_th is a much more relevant figure.

However there are several other factors that come into play now that you have brought the issues of plant potential and the difficulty of power uprates into the discussion. One of the most important ones that I have already vaguely alluded to is that all NRC-approved reactor power uprates are always measured in MW_th, not MW_e. Now keep in mind that both the gross and net electrical capacity may vary without thermal power changing due to other conditions changing (temperature for example), but these are still independent of the literal electrical generator nameplate rating. Only the literal electrical generator nameplate rating is truly fixed, yet that figure is rarely available for most types of power plants, and when it is available, it is measured in MVA, not MW.

The issue we have is simply one of having the same terminology refer to multiple different things. In common usage when applied to a power station, nameplate capacity refers to either the gross or net electrical generation capacity. Annual generation output is directly related to net generation, not gross generation. The capacity factor is directly related to net generation, not gross generation. And for many types of power plants (hydroelectric, solar, wind, etc), there is no gross output figure - only net output (or just output). So what's less confusing: giving people net output figures in some articles and gross output figures on another (with annual generation and capacity figures that only sometimes relate to the given output figures), or giving people net output figures on all articles? Garzfoth (talk) 19:59, 20 November 2017 (UTC)

Extended content

skip Remember, here we are talking about thermodynamic cycles. It is the opposite: using the net capacity when the gross one is available does not make sense. Net output is by no means a accurate value. Unfortunately, today, in the energy industry, the number of sellers without technical skills, has greatly increased and they are often the one writing the brochures. And so we may read that a certain steam turbine-generator set provides some gross power (true) and some net power (invented, arbitrary). Actually true nameplate capacity never is a net electrical output. The only context it could happen is on the commercials brochures ... (grin :-) Let us take a steam turbine genset. It has a nameplate capacity. If we talk only about that genset, it is obviously a net output; but, mind up, that genset can not work alone! It needs external services, like the feed pump (and don't forget the step-up transformers, the ones forgotten when talking about the larger photovoltaic plants ...). The nameplate capacity is a true solid value, the power output when the steam genset is feed at full steam. If I give the specified input and output pressures and temperatures, the genset will deliver the nameplate capacity. And now let us look how we get the net power. What is net output ? It is simply the electrical energy produced during a reference period as measured at the unit outlet terminals, i.e. after deducting the electrical energy taken by unit auxiliaries and the losses in step-up transformers that are considered integral parts of the unit (source: PRIS glossary but it applies also to coal plants, etc.). This value is also called Net Energy Generated, usually measured in MW·h (note: it is energy, not power). To get a net output capacity we need to average that production to the referenced observed period. And that is the first step away from having a accurate figure (remember: there are lies, damn lies and statistics ...). The problem: let us take the steam genset "model X of producer Y". It has a nameplate capacity. Has it a default net output capacity ? Noway! The steam genset model X net output changes considerably depending on: - the site climate and the season - the type of steam condenser cooling (water, draft tower, forced air cooling, etc.) - the flow and temperature of the cooling water, if available - technical management (oh, yes, it matters ...) ... and so on. A thermodynamic cycle based power plant has a different net output in winter, in summer, in the desert, on the pacific coast, etc. There is no way to tell a true net output! Only lies ... :-) What is true instead is the electrical energy measured at the plant output power meters. The only way to state a net power capacity is calculating it!!! Each year, each plant. In spite of using all plants the same steam genset model X ! More over, during life of plant, modifications or changes of the BOS (balance of system) my change significantly the net output of the plant, without changing the steam genset. For example, swapping the big old electric motors with modern high efficiency VVVF motors ups the resulting net output (less energy to the auxiliary systems means more energy out of the plant). The same happens changing the large step-up transformers with newer having less parasitic losses. All that without changing the nameplate capacity (the only true value). So, any net power value should express the conditions with which is was computed. Otherwise it may say nothing. What the gross power output states is the feasible limit capacity of the plant. In time, every upgrade approaches more and more that limit. How do we deal with this mess ? Introducing the capacity factor. Beware, it is a conventional value, without any scientific or technical meaning! So, it may happen that different source would state different values for the same machinery/plant. You have to read the fine print to understand what it is. In the document linked above there is a PRIS convention. First PRIS collects the net electrical energy produced, as measured at the unit outlet terminals (in GW·h) and the reference unit power. Together PRIS collects the monthly on-line hours and the reference hours (the relevant hours). This information is used to calculate two performance indicators: the load factor and the operating factor (note: they do not write capacity factor). All values collected for PRIS are net values (i.e. at the BOS output energy meters). PRIS also calculates losses caused by plant unavailability: planned energy losses, unplanned energy losses due to causes under the control of the management of the plant and other energy losses due to constraints that cannot be controlled by the management of the plant. While contributing to the output production, beware not to mix these with the former two factors. LF and OF are PRIS factors specific for the scope describe in their above and following linked document at end. As you may read, they are some what "complicated" and "oriented".

Wikipedia editors consensus has chosen a simpler way, collecting the only certain data: the nameplate capacity and the net production as measured at the power station output meter. I would also underline that the last section is assigned to the generator block, not the reactors. You are right that the MWth rating of a reactor or boiler is relevant, but at its own section.

You observe that the nameplate figure is not easily available, but that is no reason to change. And anyway, for nuclear plants we have the PRIS database. The fact that it is measured in MVA is not relevant, because the the power factor of a power plant is more on the unit range then else. If you look a country list, PRIS states both the Reference Unit Power which is net, i.e. estimated with a statistical calculation over time, and the Gross Electrical Capacity, also in MW, which is nothing else as than the nameplate capacity of the turbine-generator set.

And you are wrong, photovoltaic (solar ?) has a gross output figure: the DC power figure. And also hydroelectric has a nameplate capacity which is different from the actual output, having consumptions for auxiliary systems same as a steam plant, and don't forget the step-up transformer losses. About wind, you may be correct (but only for smaller farms, without step-up transformers), but that would be a reason to drop it out of the present infobox.

If follows that our capacity factor should be the net power production as found in the sources divided by the max gross power output calculated at 100% production at nameplate capacity (or gross) as found in the sources.

About the 5 year period choice: it is also the same time lapse used to collect most data by IAEA-PRIS (page 7 of document STI/DOC/010/428, the source of much of the above talk, see document.--Robertiki (talk) 03:30, 1 December 2017 (UTC)

I have a NRC source that directly and explicitly contradicts your narrative of gross power / nameplate being an accurate indication of unit output:

The nameplate power designation [gross megawatt (electrical) (MWe)] of the generator in megavolt amperes (MVA) multiplied by the nameplate rating power factor of the generator.

Note: The nameplate rating of the generator may not be indicative of the maximum or dependable capacity, because other items of equipment of lesser rating (e.g., the turbine) may limit unit output.

(from https://www.nrc.gov/docs/ML0101/ML010120458.pdf)

We are supposed to give our readers accurate information. What is more accurate: The typical sustained maximum net output to the grid, or the entirely theoretical absolute maximum output before all plant loads are met and without accounting for any other limiting components like the turbines, irregardless of how significantly those components limit the plant?

The reference unit power expressed in units of megawatt (electrical) is the maximum (electrical) power that could be maintained continuously throughout a prolonged period of operation under reference ambient conditions. The power value is measured at the unit outlet terminals, i.e. after deducting the power taken by unit auxiliaries and the losses in the transformers that are considered integral parts of the unit.

The reference unit power is expected to remain constant unless following design changes, or a new permanent authorization, the management decides to amend the original value.

(from https://www.iaea.org/PRIS/Glossary.aspx)

I find it fucking hilarious that you say "note: they do not write capacity factor". Did you even bother to read their fucking glossary? So much for that "You have to read the fine print to understand what it is", because:

Load Factor, also called Capacity Factor, for a given period, is the ratio of the energy which the power reactor unit has produced over that period divided by the energy it would have produced at its reference power capacity over that period.

Reference energy generation (net) is the energy that could be produced during a given time period if the unit were operated continuously at reference unit power.

The unit load factor is calculated for each period as shown below:
LF (%) = EG / REG x 100%
Where:
- EG = net energy generation (MW.h) for the period
- REG = reference energy generation (net) (MW.h) for the period.

This indicator reflects the actual energy utilization of the unit for electricity production.

I mean SERIOUSLY WTF. You are claiming things that are blatant falsehoods! This is utterly unacceptable.

I see utterly no evidence whatsoever of consensus. Please show me the previous talk page discussions where it was decided by consensus to utilize gross solely rather than net or either gross/net. Maybe I missed them. But until Rehman changed things in November 2010 for no discernable reason (his edit summary does not explain anything and is actually excessively vague) from "installed capacity" to "gross installed capacity" (diff), the consensus seemed to indicate otherwise.

The definition of RUP does not include planned or unplanned losses. In fact in http://www-pub.iaea.org/MTCD/Publications/PDF/TRS428_web.pdf on page 21 (PDF page 30) they explicitly show that reference power excludes all losses.

Transformer losses are inherent to all AC power sources... Auxiliary consumption at a hydro plant is a minuscule fraction of what it is at a thermal plant. PV DC output is not comparable to gross output at other types of power plants as this power must be converted before use on AC power grids, which inherently involves unavoidable and unsubsidizable/unignorable losses. Your logic for dropping wind from this infobox (and moving it into infobox dam of all places) makes absolutely no sense whatsoever and is currently unsupported by anyone other than yourself.

It absolutely does not follow that capacity factor should be net power production capacity — are you out of your mind? Capacity factor shows you what proportion of the maximum station (net) output is actually being produced — entirely different!

You clearly misread the PRIS document, as the data updated every five years is data that is only available to registered users and does not include anything relevant to this discussion outside of the thermal power, which is certainly nowhere near the primary issue here. PRIS collects the RUP at least annually via the production reports.

How about this: Why don't we split the infobox power station total power capacity values into two parts — Generator nameplate capacity (ps_gen_electrical_capacity) and Station nameplate capacity (ps_electrical_capacity)? The first one would denote the sum of literal generator nameplate or gross output capacities for all units, while the second one would denote the sum of rated/reference/station/typical output capacities for all units. This would resolve the issue and expand the amount of data, which is beneficial for everyone. Garzfoth (talk) 08:04, 1 December 2017 (UTC)

I've made the above-described changes in the sandbox. You can view the relevant test case at Template:Infobox_power_station/testcases#Most_parameters_(updated). Garzfoth (talk) 08:17, 1 December 2017 (UTC)

Extended content

No choice is perfect, every unit dealing with the real world has drawbacks. But net power is the least accurate choice. The NRC source is correct, if you prefer, discard my assumption that high power transmission is associated with a high power factor value, but it doesn't matter: if the nameplate rated power factor is substantially' different from 1, simply make the multiplication and get the cited nameplate power designation otherwise knowned as gross megawatt (electrical) (MWe). And if, the turbine limits the generator output (possible, but non economically likely), there is surely a nameplate mechanical output value for the turbine. Which way, you have a accurate value of what the generator may deliver. Surely an order more accurate than net power data. You ask me: "What is more accurate: The typical sustained maximum net output to the grid, or the entirely theoretical absolute maximum output before all plant loads are met and without accounting for any other limiting components like the turbines, irregardless of how significantly those components limit the plant?". First: what you describe as "typical sustained maximum net output to the grid" is no way a accurate value, because it needs to be calculated each time and changes each period you examine it. It is what I call a artificial assumption, not a accurate information. Need proof ? In 2016 they declare the plant on-line for 7925 hours. At the reference unit power of 948 MW that would yield "at least" 7,513 GWh. But the production was 7,629 GWh, i.e. we had 116 GWh more. That means that at times the net power output of that reactor was more than 948 MW (about 15 MW more averaging). In 2015 we have 72 GWh surplus, (about 9 MW more averaging). Check the other years and say to me that the reference power is a accurate value ... Instead the absolute maximum output before all plant loads are met (and by no way not accounting for a limiting turbine) is a accurate and repeatable value. Every time, under blizzard or a scorching sun. About the capacity factor versus load factor, I acknowledge my mistake, but that changes nothing. I hope you understand I was in good faith, writing in a hurry.

About consensus, Rehman modification in 2010 (see Talk:installed capacity net or gross?), with no effective challenge until now, and my support, count as consensus. It may change now, but you may have to give me a convincing reason.

Extended content

Let us take an example: North Anna Nuclear Generating Station. PRIS states the following data: Gross capacity 990 MWe (which as explained is accurate and definite value) Net capacity 948 MWe (which is an averaged estimated value) Electricity supplied (38,543 GWh 2012-2016, i.e. 7,709 GWh average per year). If we take 948 as capacity, the REG is 8,327 which results in a LF = 92,6%). Awesome! But we have lost some information. See what happens if we take the gross capacity, 990, which yields a REG of 8,696 which results in a LF = 88,6%. And that is a different story, because it teaches us that there is something more under the "hood" of that reactor. Something that is missed if you look at the net LF of 92,6%. The PRIS data focus the management style, i.e. production at status quo. I would prefer that we look at the plant characteristics, at what is "hidden" under the LF convention.

Anyway, I would prefer hard data, not "estimated" or "calculated" data. Gross capacity is hard data (you read it from a plate). Net production is hard data (you read it a the power meters). It follows that the only sensible definition of power capacity would use that two "accurate" data. As I have done calculating 88,6%.
I don't agree expanding the infobox (my opinion). There is all the place you want in the article body to detail net and gross values, as ever has been done. --Robertiki (talk) 02:35, 2 December 2017 (UTC)

http://www-pub.iaea.org/MTCD/Publications/PDF/Pub1484_web.pdf

As a part of the main exciter installation, a new grid stability study was required to understand the effect(s) on the grid of operating at 1265 MVa (1138 MW(e)). The previous grid stability studies had not been performed at the TPU output level since CPS did not have the capability to generate that level of MW(e), however, with the addition of the new exciter, this would allow generation at TPU conditions (1138 MW(e) @ 0.9Pf) pending the resolution of the items discussed above related to testing, margin, etc. The results of this study (entitled “Midwest ISO IP10 (36629-02) System Impact Restudy, dated September 2007”) was that a fault was identified which could potentially take CPS out of synchronism if operated beyond 1115 MW(e). The proposed “fix” for this potential grid concern is the installation of an additional breaker in the switchyard. The study results showed that below 1115 MW(e) CPS remained in synchronism after the fault, however, at an output of >1115 MW(e) gross, there would be problems if there was a fault and breaker 4518 did not respond in a defined amount of time. As a result, Clinton Station is limited to 1115 MW(e) gross. Additionally, other parameters such as steam flow and feedwater suction pressure are nearing their margin limitation. As such, prior to increasing power beyond the present limitations as noted in our operating procedures, CPS has made the decision to perform detailed studies as to the correct course of action surrounding the removal of these limitations. Pending results of those detailed studies (to be performed at a later date) and also pending the acceptance of the General Electric MELLLA+ topical report by the NRC, CPS will remain at its present power level.

The following provides the major modifications with a short explanation for each. The final guaranteed design power output of CPS is 1138 MW(e) at 0.9Pf or 1265 MVa.

https://www.iaea.org/pris/CountryStatistics/ReactorDetails.aspx?current=742

Reference Unit Power (Net Capacity): 1065 MW_e
Gross Capacity: 1098 MW_e

1098 != 1138; 1098 != 1115

Another example: http://www.tvo.fi/uploads/julkaisut/tiedostot/TVO_Tekninenesite_ENG.pdf

Generator
Nominal rating MVA 990
Power factor, nominal cos 0.9

Computed: 990 * 0.9 = 891

https://www.iaea.org/PRIS/CountryStatistics/ReactorDetails.aspx?current=159 / https://www.iaea.org/PRIS/CountryStatistics/ReactorDetails.aspx?current=160

Reference Unit Power (Net Capacity): 880 MW_e
Gross Capacity: 910 MW_e

910 != 891

Therefore, the gross capacity value in PRIS is not at all representative of the generator's true gross nameplate value, as proven by three distinct examples. Your argument thus severely lacks in validity — it is not supportable, quite the opposite in fact, as it is now disproven.

I am (still!) willing to compromise on this issue by expanding the infobox. This is a solution that will resolve some major issues, give everyone access to more data, and make the infobox clearer. There are no major downsides to this solution. Why do you oppose it? If the generator/gross (gross would likely be the more appropriate name) nameplate value deserves to be in the infobox, surely the station/net (either name is appropriate) nameplate value also deserves to be in it as well? You cannot honestly argue that depriving our readers of information is a good idea, especially when the information is coming directly from PRIS and is hardly a minor data point. We have fields in the infobox that rarely see any use as it is (np_fuel_supplier, np_fuel_type), what harm is there in adding one that will see extensive use? Garzfoth (talk) 02:04, 4 December 2017 (UTC)

Another major example: http://www.neimagazine.com/features/featurealmaraz-12-power-uprate/

The new intercooled alternators are designed and manufactured by Siemens. The specification is 1180 MVA at 1500 rpm, power factor of 0.9 and 75 psig hydrogen pressure. The generation voltage, 21 kV, is unchanged, but the new alternator allows higher voltage variations, -8.5% to +6.5% (19.22 kV to 22.37 kV), allowing greater flexibility to suit the requirements of the network. The ratio of current in to current out becomes 40000 A/5 A and incorporates three new transformers in the generation terminal.

Computed: 1180 * 0.9 = 1062

https://www.iaea.org/pris/CountryStatistics/ReactorDetails.aspx?current=153 / https://www.iaea.org/PRIS/CountryStatistics/ReactorDetails.aspx?current=154

Reference Unit Power (Net Capacity): 1011 MW_e
Gross Capacity: 1049 MW_e

Reference Unit Power (Net Capacity): 1006 MW_e
Gross Capacity: 1044 MW_e

1049 != 1062; 1044 != 1062

It's quite clear that the gross capacity value is, just as PRIS defines it, a so-called "soft" value (by your terminology at least). The definition is pretty obvious in retrospect, I probably should have brought it up earlier:

Reference gross electrical power of the plant expressed in MW(e).

The maximum (electrical) power that could be maintained continuously throughout a prolonged period of operation under reference ambient conditions. The gross electrical power is measured at the output terminals of the turbine generator.

So it looks like your argument has collapsed entirely. Please explain your objection to listing gross+station nameplates separately in the infobox. Garzfoth (talk) 15:36, 4 December 2017 (UTC)

I understand your arguments, but you are missing the point, what ever limits externally the genset output, goes in the article body. But back to the infobox(here I am modifying my previous proposal): by calculating the Capacity factor, we are slipping into violation of no original research rule. Simple math is acceptable, but if there is to be consensus about the underlying data, than that is no more simple math. Instead of having to agree that we don't agree, let us leave the dispute/selection to external sources (PRIS, EIA, various country network operators ...).

Section break

Ping Beagel, Frietjes, NortyNort, Rehman, summing up I am proposing:

to confirm (as is now): ps_electrical_capacity as

current gross installed capacity

as given from the genset plate (or sum of gensets);

to add that: ps_electrical_cap_fac

value should originate from a reliable source, not to be calculated

and to delete the "gross production" option, leaving ps_annual_generation

net production

because PRIS and EIA provide net production, as it is a metered, reliable value.

To remove confusion, I propose to drop the "gross" options in the actual description of the ps_annual_gen_year, leaving only:

Planned net (if given data is a planned estimate net output)

YYYY net (if given data is year YYYY net output)

Annual net (if given data is a average net output)

--Robertiki (talk) 05:11, 7 December 2017 (UTC)

I agree with the above statement by Robertiki, on basis that this is what has been followed currently anyway, and that no new changes are required (please correct me if I misunderstood). But when it comes to the ps_annual_generation parameter, I am leaning towards completely removing all options, including the parameter ps_annual_gen_year entirely, and sticking to only one standard, preferably to the net annual average. This is because of three reasons:

1. Other than the core designers of this template, most other editors will not really bother going through our delicate instructions on the documentation page. They will simply read the parameter, and enter data based on the most basic understanding of that particular parameter name.
2. Wikidata support (i.e. completely automated filling of infoboxes) will happen sooner or later. And to make sure we can accommodate the transition, we need to remove unnecessary complexity in the template, and accommodate simple straight-forward parameters.
3. As accepted in the WP:Energy community before, this infobox is already with too much parameters. And we should reduce where ever we can. Keeping MOS:IBX in mind, it is essential to keep the infobox as a summary of key facts already in the article text. We don't need to be complicate things by having every single fact in all variants, in the infobox itself.

Best regards, Rehman 05:38, 7 December 2017 (UTC)

I can live with the removal of ps_annual_gen_year parameter and stick to net annual average (i.e. 5 year average, if data is available, else we must live with what we get). --Robertiki (talk) 06:32, 7 December 2017 (UTC)

I don't think anyone is listening to me. I have explicitly disproven the argument that the gross power output rating listed by the IAEA in PRIS corresponds to the nameplate rating on the electrical generator (i.e. I have proven that it does not correspond to the nameplate rating as Robertiki understands it), utterly ruining the entire argument for exclusively using gross power output in the ps_electrical_capacity param. Since proving my point nobody has bothered justifying the use of gross power output instead of net power output, either/or, or both. Please stop ignoring me and start responding to this pressing concern. Garzfoth (talk) 07:17, 11 December 2017 (UTC)

To put it frankly, I did stop reading your posts the moment I came across swear words and whatnot. But doing so is wrong on my side, hence I apologise. Moving on to the topic, as far as I can tell, ps_electrical_capacity has always been used as (unit at nameplate capacity) x (number of units). It is something that is more or less derived and used on-wiki, simply because the gross or net capacity of an entire given power station, will differ depending on various technicalities/country rules/policies/etc. Hence it is safe to simply settle with the above. Rehman 13:47, 11 December 2017 (UTC)

• I think this template should include only the nameplate capacity. More detailed information about net capacity etc should be included in the body text. I also can agree with removal of ps_annual_gen_year. At the same time, I think we should be more flexible and to allow using ps_annual_generation for both: annual generation in the given year and net annual average. Of course, the documentation should be make clear that in that case it should be added in the brackets for which period it applies (e.g. (2016); (average)). In the case of capacity factor, I am not sure if it should be included in the infobox. If there is consensus to include it, it should include a figure from a reliable source, no way it would be calculated by editors. Beagel (talk) 12:09, 16 December 2017 (UTC)

I am leaning to removing the capacity factor. I have found it came from the old infobox wind farm. I could envision a new technical infobox where parameters like net power versus gross power, capacity factor and other data could be given and to be added under a Plant technical data section. --Robertiki (talk) 20:17, 17 December 2017 (UTC)

I made the changes to documentation and template and just removed about fifty instances of the ps_annual_gen_year parameter. Now generation data is net, i.e. what sources give us, and the nameplate capacity is confirmed as gross. I added a clarification that capacity factor should originate from a referenced source. Should we add "that it should not be calculated ?" --Robertiki (talk) 22:02, 2 January 2018 (UTC)

Wikipedia:Wikidata/2018 Infobox RfC

Hi. Your opinion at the above RFC is deeply valued. The RFC decides if Wikipedia would support data from Wikidata for use in infoboxes (Example - notice the infobox in edit mode). Thank you, Rehman 17:26, 11 April 2018 (UTC)

Fix link for "mothball"

When M is used as the status parameter, the link is to the wiktionary page "Mothball" (capitalized), which is a deleted page. The link should be to "mothball" (lowercase). A minor annoyance, but something that should be quick to fix. AHeneen (talk) 10:18, 30 May 2018 (UTC)

Thank you, AHeneen. It's fixed. Rehman 14:58, 30 May 2018 (UTC)